from:"Jan Bernhardt"


[ 
https://issues.apache.org/jira/browse/SYNCOPE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588224#comment-13588224
 ] 

Jan Bernhardt commented on SYNCOPE-324:
---

+1 Sounds like a real good idea.

I'll update Test-Cases and Console and see, if we run into any issues with 
Francescos approach.

 Return User instead of Boolean from REST username + password query
 --

 Key: SYNCOPE-324
 URL: https://issues.apache.org/jira/browse/SYNCOPE-324
 Project: Syncope
  Issue Type: Improvement
Reporter: Colm O hEigeartaigh
 Fix For: 1.1.0


 The REST API GET /users?username={username}pwd={password} currently returns 
 a boolean. This task is to return the User instead, as per the mailing list 
 discussion here:
 http://syncope-dev.1063484.n5.nabble.com/API-query-td5712965.html
 If authentication is successful we should return 200 OK, if authentication 
 fails we should return 404 NOT FOUND. 
 Caching should be disabled for this URL.

--
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] [Updated] (SYNCOPE-324) Return User instead of Boolean from REST username + password query


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt updated SYNCOPE-324:
--

Assignee: Jan Bernhardt

 Return User instead of Boolean from REST username + password query
 --

 Key: SYNCOPE-324
 URL: https://issues.apache.org/jira/browse/SYNCOPE-324
 Project: Syncope
  Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 The REST API GET /users?username={username}pwd={password} currently returns 
 a boolean. This task is to return the User instead, as per the mailing list 
 discussion here:
 http://syncope-dev.1063484.n5.nabble.com/API-query-td5712965.html
 If authentication is successful we should return 200 OK, if authentication 
 fails we should return 404 NOT FOUND. 
 Caching should be disabled for this URL.

--
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] [Reopened] (SYNCOPE-312) Introducing UserWorkflowService


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt reopened SYNCOPE-312:
---


Documentation needs to be updated:
https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade

 Introducing UserWorkflowService
 ---

 Key: SYNCOPE-312
 URL: https://issues.apache.org/jira/browse/SYNCOPE-312
 Project: Syncope
  Issue Type: Bug
  Components: common
Reporter: Jan Bernhardt
Assignee: Christian Schneider
Priority: Minor
  Labels: refactoring
 Fix For: 1.1.0


 As agreed on dev mailinglist [1] task of this Issue is to create a 
 UserWorkflowService Interface and move workflow related methods from 
 UserService to UserWorkflowService.
 [1] 
 http://syncope-dev.1063484.n5.nabble.com/DISCUSS-User-Service-td5712640.html

--
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] [Resolved] (SYNCOPE-324) Return User instead of Boolean from REST username + password query


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt resolved SYNCOPE-324.
---

Resolution: Fixed

Code  Documentation updated.
Code in Console will be updated in 1.2.x release, after switching to CXF

 Return User instead of Boolean from REST username + password query
 --

 Key: SYNCOPE-324
 URL: https://issues.apache.org/jira/browse/SYNCOPE-324
 Project: Syncope
  Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 The REST API GET /users?username={username}pwd={password} currently returns 
 a boolean. This task is to return the User instead, as per the mailing list 
 discussion here:
 http://syncope-dev.1063484.n5.nabble.com/API-query-td5712965.html
 If authentication is successful we should return 200 OK, if authentication 
 fails we should return 404 NOT FOUND. 
 Caching should be disabled for this URL.

--
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

Bug in trunk for updating users?

2013-02-26 Thread Jan Bernhardt

Hi Syncoper,

I just checked out latest version of trunk and after installing syncope via 
maven, I started standalone distribution.
When I try to open and save a user (Puccini) I get an InternalServer Error

SCHWERWIEGEND: Servlet.service() for servlet [syncope-core-rest] in context 
with path [/syncope] threw exception [Request processing failed; nested 
exception is org.activiti.engine.ActivitiException: execution 0 doesn't exist] 
with root cause
org.activiti.engine.ActivitiException: execution 0 doesn't exist
at 
org.activiti.engine.impl.cmd.GetExecutionVariableCmd.execute(GetExecutionVariableCmd.java:52)
at 
org.activiti.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
at 
org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:60)
at 
org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
at 
org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:131)
at 
org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
at 
org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:32)
at 
org.activiti.engine.impl.RuntimeServiceImpl.getVariable(RuntimeServiceImpl.java:115)
at 
org.apache.syncope.core.workflow.user.activiti.ActivitiUserWorkflowAdapter.doUpdate(ActivitiUserWorkflowAdapter.java:318)
at 
org.apache.syncope.core.workflow.user.AbstractUserWorkflowAdapter.update(AbstractUserWorkflowAdapter.java:72)

Am I doing something wrong or can someone else confirm that this is a bug?

Best regards.
Jan

RE: Bug in trunk for updating users?

2013-02-26 Thread Jan Bernhardt

Ah OK, creating a new user and updating that one works fine.

I was expecting that SYNCOPE-265 is only about fixing schema validation errors 
and my exception was related to Activity workflow. 
Anyhow thanks for pointing me to the right direction.

Best regards.
Jan


 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Dienstag, 26. Februar 2013 16:12
 To: dev@syncope.apache.org
 Subject: Re: Bug in trunk for updating users?
 
 On 26/02/2013 16:08, Jan Bernhardt wrote:
  Hi Syncoper,
 
  I just checked out latest version of trunk and after installing syncope via
 maven, I started standalone distribution.
  When I try to open and save a user (Puccini) I get an InternalServer
  Error
 
  SCHWERWIEGEND: Servlet.service() for servlet [syncope-core-rest] in
  context with path [/syncope] threw exception [Request processing
  failed; nested exception is org.activiti.engine.ActivitiException:
  execution 0 doesn't exist] with root cause
  org.activiti.engine.ActivitiException: execution 0 doesn't exist
   at
 org.activiti.engine.impl.cmd.GetExecutionVariableCmd.execute(GetExecutio
 nVariableCmd.java:52)
   at
 org.activiti.engine.impl.interceptor.CommandExecutorImpl.execute(Comma
 ndExecutorImpl.java:24)
   at
 org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(C
 ommandContextInterceptor.java:60)
   at
 org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTra
 nsactionInterceptor.java:42)
   at
 org.springframework.transaction.support.TransactionTemplate.execute(Tra
 nsactionTemplate.java:131)
   at
 org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInt
 erceptor.java:40)
   at
 org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.j
 ava:32)
   at
 org.activiti.engine.impl.RuntimeServiceImpl.getVariable(RuntimeServiceImpl
 .java:115)
   at
 org.apache.syncope.core.workflow.user.activiti.ActivitiUserWorkflowAdapte
 r.doUpdate(ActivitiUserWorkflowAdapter.java:318)
   at
 
 org.apache.syncope.core.workflow.user.AbstractUserWorkflowAdapter.upd
 a
  te(AbstractUserWorkflowAdapter.java:72)
 
  Am I doing something wrong or can someone else confirm that this is a
 bug?
 
 Currently the test users cannot be updated or deleted: this is under work by
 Fabio as per SYNCOPE-265.
 
 Just create new users and work with them in the meanwhile.
 
 Regards.
 
 --
 Francesco Chicchiriccò
 
 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: API query

2013-02-21 Thread Jan Bernhardt

Hi Colm,

+1 for returning user instead of Boolean for authentication process. I wasn't 
happy about the current handling anyway, since URL pattern did not reflect a 
different response type. This way username and password can be seen as search 
queries for a user with matching username and password. If authentication is 
successful we should return 200 OK, if authentication fails we should return 
404 NOT FOUND.

This way we could support both GET for returning matching user (including 
roles) or HEAD if only Authentication result (TRUE : 200 or FALSE : 404) is 
required.

Applying these changes should be relatively easy. If no other syncope users 
raise concerns about this, you can create a JIRA issue for this.

And we should also take Sergeys comment into account and disable caching for 
this authentication URL.

Best regards.
Jan

 -Original Message-
 From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
 Sent: Mittwoch, 20. Februar 2013 17:06
 To: Jan Bernhardt
 Cc: dev@syncope.apache.org
 Subject: Re: API query
 
 A second thought is that a API to return the User matching the given
 username + password would be quite nice, unless there is another way of
 doing this that I am missing. WDYT?
 
 Colm.
 
 On Wed, Feb 20, 2013 at 4:04 PM, Colm O hEigeartaigh
 cohei...@apache.orgwrote:
 
 
  Thanks Jan, I have updated it. The old API method returns null if
  the User does not exist, whereas the new API does not seem to return
 anything.
  Would it not be better in both cases to return false explicitly? Or
  are there backwards compatilbity concerns about changing this?
 
  Colm.
 
 
  On Wed, Feb 20, 2013 at 4:00 PM, Jan Bernhardt
 jbernha...@talend.comwrote:
 
  Hi Colm,
 
  The description is wrong, this method returns a boolean.
 
  Best regards.
  Jan
 
   -Original Message-
   From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
   Sent: Mittwoch, 20. Februar 2013 16:48
   To: dev@syncope.apache.org
   Subject: API query
  
   Hi all,
  
   From the wiki:
  
  
 https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrad
   e#
   RESTAPIupgrade-UserService
  
   GET /user/verifyPassword/{username}?password={password}  GET
   /users?username={username}pwd={password}  Returns user if
 username
   and password match with an existing account.
   This method actually returns a boolean not the user, and so the
  description is
   invalid.
  
   Could someone clarify whether the new API is intended to return a
  boolean
   or the User?
  
   Colm.
  
  
   --
   Colm O hEigeartaigh
  
   Talend Community Coder
   http://coders.talend.com
 
 
 
 
  --
  Colm O hEigeartaigh
 
  Talend Community Coder
  http://coders.talend.com
 
 
 
 
 --
 Colm O hEigeartaigh
 
 Talend Community Coder
 http://coders.talend.com

RE: external property file for core

2013-02-21 Thread Jan Bernhardt

+1 for PropertyPlaceholders.

Best regards.
Jan

 -Original Message-
 From: ernst Developer [mailto:ernst.develo...@gmail.com]
 Sent: Donnerstag, 21. Februar 2013 10:42
 To: dev@syncope.apache.org
 Subject: external property file for core

 Hi,

 With SYNCOPE-244 we now have the option to use an external property file
 for syncope console. That is a very useful enhancement.

 I would like to have the same option for syncope core.

 At the moment all property files are loaded in the syncopeContext.xml file.
 I guess it is possible to add the same PropertyPlaceholderConfigurer bean in
 this file, with the lowest order, and we anyone can define its own properties
 in the external property file. In this way, it is possible to use different
 properties, without a new build.

 I think it's just adding (as in applicationContext.xml in the console):

 *bean id=systemPropertyConfigurer
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfig
 urer
 *
 *  property name=order value=1/*
 *  property name=location
 value=file:#{(systemProperties['syncope.console.configuration'])}/*
 *  property name=ignoreResourceNotFound value=true/*
 *  property name=ignoreUnresolvablePlaceholders value=true/*
 */bean*
 *
 *
 And add an order property on the bean:
 *bean
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfig
 urer
 *

 What do you think?

 Regards,
 Ernst

RE: [CONF] Apache Syncope REST API upgrade

2013-02-20 Thread Jan Bernhardt

Hi Syncoper,

Here are some more best practices for RESTful APIs.

Use PUT if you want to persist an entity as it is. Use POST from any kind of 
processes.

Hence I would recommend to change:
PUT /connectors/reload

To

POST /connectors/reload

Best regards.
Jan

From: conflue...@apache.org [mailto:conflue...@apache.org]
Sent: Mittwoch, 20. Februar 2013 12:34
To: Jan Bernhardt
Subject: [CONF] Apache Syncope  REST API upgrade

REST API 
upgradehttps://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade
Page edited by Francesco 
Chicchiriccohttps://cwiki.apache.org/confluence/display/~ilgrosso

Changes (2)
...

| GET /connector/\{connectorId\}/configurationProperty/list | GET 
/connectors/\{connectorId\}/configuration | Returns configuration for selected 
connector. |
| POST /connector/check | POST /connectors/check | Checks if a connection can 
be established. |

| GET /connector/\{resourceName\}/connectorBean 
/connector/\{resourceName\}/readByResource | GET 
/connectors;resourceName=\{connectorId\} | Returns connector for resourceName. |

| PUT /connector/reload | PUT /connectors/reload | Reload all connector bundles 
and instances. |


h2. Entitlement Service

...

Full Content
[https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif]

Version warning
In Syncope 1.1.0 a new REST interface was introduced (referred as new in the 
following).
The REST interface available in 1.0.X (referred as old in the following) is 
still present but will be removed from releases = 1.2.0.

This page shall give you an overview of old and new REST API.

  *   Configuration Service
  *   Connector Service
  *   Entitlement Service
  *   Logger Service
  *   Notification Service
  *   Policy Service
  *   Report Service
  *   Resource Service
  *   Role Service
  *   Schema Service
  *   Task Service
  *   User Service
  *   UserRequest Service
  *   Workflow Service
Main focus on redesign REST interface was to apply RESTful Best 
Practiceshttp://www.slideshare.net/calamitas/restful-best-practices

  *   use HTTP operations instead of URL encoded operation names
  *   GET does not modify any object (read-only safety operation)
  *   PUT and DELETE are idempotent operations
[*]   PUT and DELETE do not return (old) object any longer, except for 
Roles and Users, since they contain propagation status information

  *   CREATE operations return location URL in header for newly created object
[*]   In addition to that unique identifier of resource is also send in 
response header (org.apache.syncope.resource.id)
While redesigning interface, we also made changes to exception 
handlinghttps://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions.
Configuration Service
Old URL

New URL

Comment

POST /configuration/create

POST /configurations

Creates a new Configuration.

GET /configuration/read/{key}

GET /configurations/{key}

Returns configuration element with matching key.

GET /configuration/list

GET /configurations

Returns a list of all configuration elements.

POST /configuration/update

PUT /configurations/{key}

Overwrites configuration element with matching key.

GET /configuration/delete/{key}

DELETE /configurations/{key}

Deletes configuration with matching key.

Old URL

New URL

Comment

GET /configuration/validators

GET /configurations/validators

Returns a list of known validators.

GET /configuration/mailTemplates

GET /configurations/mailTemplates

Returns a list of known mail-templates.

GET /configuration/dbexport

GET /configurations/dbDump

Returns configuration as an downloadable content.xml database export file.

Connector Service
Old URL

New URL

Comment

POST /connector/create

POST /connectors

Creates a new connector instance.

GET /connector/read/{connectorId}

GET /connectors/{connectorId}

Returns connector with matching id.

GET /connector/list?lang={lang}

GET /connectors?lang={lang}

Returns a list of all connectors. Default language is English.

POST /connector/update

PUT /connectors/{connectorId}

Overwrites connector with matching key.

GET /connector/delete/{connectorId}

DELETE /connectors/{connectorId}

Deletes connector with matching id.

Old URL

New URL

Comment

GET /connector/bundle/list?lang={lang}

GET /connectors/bundles?lang={lang}

Returns known bundles. Default language is English.

POST /connector/schema/list?showall={showall}

POST /connectors/{connectorId}/schemas?showAll={showall}

Returns schema names for connector. Default is showAll=false.

GET /connector/{connectorId}/configurationProperty/list

GET /connectors/{connectorId}/configuration

Returns configuration for selected connector.

POST /connector/check

POST /connectors/check

Checks if a connection can be established.

GET /connector/{resourceName}/readByResource

GET /connectors;resourceName={connectorId}

Returns connector for resourceName.

PUT /connector/reload

PUT /connectors/reload

Reload all connector bundles and instances.

Entitlement Service
Old URL

New URL

RE: API query

2013-02-20 Thread Jan Bernhardt

Hi Colm,

The description is wrong, this method returns a boolean.

Best regards.
Jan

 -Original Message-
 From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
 Sent: Mittwoch, 20. Februar 2013 16:48
 To: dev@syncope.apache.org
 Subject: API query
 
 Hi all,
 
 From the wiki:
 
 https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
 RESTAPIupgrade-UserService
 
 GET /user/verifyPassword/{username}?password={password}  GET
 /users?username={username}pwd={password}  Returns user if username
 and password match with an existing account.
 This method actually returns a boolean not the user, and so the description is
 invalid.
 
 Could someone clarify whether the new API is intended to return a boolean
 or the User?
 
 Colm.
 
 
 --
 Colm O hEigeartaigh
 
 Talend Community Coder
 http://coders.talend.com

[jira] [Resolved] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)

2013-02-14 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt resolved SYNCOPE-231.
---

Resolution: Fixed

CXF is now fully functional integrated into CXF. All Integration-Test are 
successful.
Thanks to everyone participating with this issue.

 Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack)
 --

 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.1.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

RE: [DISCUSS] User Service

2013-02-08 Thread Jan Bernhardt

Hi syncoper,

I do not even see methods in RoleService that should be moved into a different 
ServiceInterface! Workflow controller is used in RoleController but just for 
CRUD operations, no direct access, so this is mostly transparent to user.

But I completely agree with Christian, that direct workflow operations 
identified by TaskID should be moved out of UserService. They are used in 
context of users (currently) but can be used also in other contexts. This is 
why I would move the following method to WorkflowService:

@POST
@Path(workflow/tasks/{taskId}/claim)
WorkflowFormTO claimForm(@PathParam(taskId) String taskId);

@POST
@Path(workflow/tasks/{taskId}/execute)
UserTO executeWorkflow(@PathParam(taskId) String taskId, UserTO userTO);

@GET
@Path(workflow/form)
ListWorkflowFormTO getForms();

@POST
@Path(workflow/form)
UserTO submitForm(WorkflowFormTO form);

Since this next method contains a userId but is related to workflow activity, 
I'm not sure what to do with it. I guess is should remain in UserService, to 
not have an dependency from WorkflowService to UserService.

@GET
@Path({userId}/workflow/form)
WorkflowFormTO getFormForUser(@PathParam(userId) Long userId);

Best regards.
Jan


 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Dienstag, 5. Februar 2013 11:03
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] User Service
 
 On 05/02/2013 10:01, Christian Schneider wrote:
  On 04.02.2013 18:10, Francesco Chicchiriccò wrote:
  I agree with you that WorkflowController and the workflow methods in
  UserController do not belong together. On the other hand I think it
  may be a good idea to separate them from the UserService. So would
  it make sense to have a UserWorkflowService? This is supported by
  the fact that we already have a separate ApprovalRestClient in the client
 module.
  I am still not completely convinced of the rationale for creating
  such new UserWorkflowService (and RoleWorkflowService, please don't
  forget that also roles are workflow-enabled).
  We will end up with UserService / RoleService for read-only
  operations and UserWorkflowService / RoleWorkflowService for
  write-only
  operations: does it make sense?
  UserService and RoleService contain the full set of crud operations.
  So why would they be readonly?
  I am not absolutely sure if separating the interfaces makes sense but
  I think it could. One indicator is that the UserService always works
  with the userId or userName while the workflow methods normally use
  taskId as a key. So I think this indicates that the resource we are
  handling is not the user but rather a workflow identified by a task.
  So naming it UserWorkflowService sounds intuitive to me.
 
 Ok, could you please detail which methods from the current UserService and
 RoleService you would like to move into new UserWorkflowService /
 RoleWorkflowService?
 
  Why make this distinction for SyncopeUser and not for any other
  entity? We expose internal ids for everything.
  That is true. It would not make too much sense to make an exemption
  for User.
  One other thing we could consider is using a redirect from the user
  based rest resource to the id based resource. So when you do a get
  on users/readByUsername/{username} we could redirect to
 users/{username}.
 
  For the status changing methods like users/activate/{userid} we
  could instead use: users/{userId}/status.
  You could send put with body active to users/{userId}/status to make
  a user active. Or you could get users/{userId}/status to retrieve
  the status of a user.
  As explained in another e-mail thread, it does not make sense to set
  a generic status for users: activate an user is not the same as
  setting its status to active (and so on): the difference is given
  by the workflow definition that any single project could implement to
  suit its own needs.
 
  For these reasons, we should try to find a way to express the operations:
* activate()
* suspend()
* reactivate()
 
  in RESTful terms.
  But putting user status is not an option, IMO.
  I will experiment with introducing methods that take a userId or
  userName String. So at least we can cut half of the methods for status
  changes.
 
  Is it ok to remove the reactivate and use activate with a null token
  instead or is this too different in meaning?
 
 They have different meaning and are mapped to different methods on the
 underlying UserWorkflowAdapter, so we should keed them distinct.
 
 Regards.
 
 --
 Francesco Chicchiriccò
 
 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

[jira] [Created] (SYNCOPE-312) Introducing UserWorkflowService

2013-02-08 Thread Jan Bernhardt (JIRA)

Jan Bernhardt created SYNCOPE-312:
-

 Summary: Introducing UserWorkflowService
 Key: SYNCOPE-312
 URL: https://issues.apache.org/jira/browse/SYNCOPE-312
 Project: Syncope
  Issue Type: Bug
  Components: common
Reporter: Jan Bernhardt
Priority: Minor
 Fix For: 1.1.0


As agreed on dev mailinglist [1] task of this Issue is to create a 
UserWorkflowService Interface and move workflow related methods from 
UserService to UserWorkflowService.

[1] http://syncope-dev.1063484.n5.nabble.com/DISCUSS-User-Service-td5712640.html

--
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

RE: dbDump in ReportService and ConfigurationService

2013-02-07 Thread Jan Bernhardt

+1

Best regards.
Jan

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 7. Februar 2013 10:36
 To: dev@syncope.apache.org
 Subject: Re: dbDump in ReportService and ConfigurationService

 On 06/02/2013 12:08, Jan Bernhardt wrote:
  Hi Francesco,
  From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]

  Hi all,
  I am currently completing some modifications started yesterday with
  ConfigurationServiceProxy.dbExport() that will involve some
  refactoring on console's HttpResourceStream and also to core's
 ReportTestITCase.

  Basically, I would like to encapsulate the logic for handling streams
  (content.xml and reports in various formats) in the relevant service
 proxies.

  While doing this, I've just noticed that ReportSevice has

@GET
@Path(executions/{executionId}/dbDump)
Response exportExecutionResult(@PathParam(executionId) Long
  executionId,
@QueryParam(format) ReportExecExportFormat fmt);

  while ConfigurationService has

@GET
@Path(dbDump)
Response dbExport();

  Any special reason for this dbDump?
  No there is no special reason for dbDump. (Code looks to me, as if this is
 what happens here.) I only tried to find a consistent manner, who to title a
 downloadable stream. I'm completely open for any
 suggestions/improvements for a different URL path.

 What about

  @GET
  @Path(executions/{executionId}/stream)
  Response exportExecutionResult(@PathParam(executionId) Long
 executionId,
  @QueryParam(format) ReportExecExportFormat fmt);

 and

  @GET
  @Path(stream)
  Response dbExport();

 ?

 Regards.

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: Add a new method into the PolicyService

2013-02-07 Thread Jan Bernhardt

Hi Fabio,

 -Original Message-
 From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
 Sent: Donnerstag, 7. Februar 2013 11:04
 To: dev@syncope.apache.org
 Subject: Add a new method into the PolicyService

 Hi All,
 I have to add a new rest method to retrieve sync policy correlation rules.
 As you can see this info is just related to the sync policies.

 Since the PolicyService take the policy type as part of the path
 (@Path(policies/{type})) how do you suggest to introduce a client method
 to retrieve this info?
 Should I do something like the following

 @GET
@Path(correlationRules)
 ListString getCorrelationRules(@PathParam(type) PolicyType type);

 throwing an IllegalArgumentException in case of password or account type?

Since PolicyType  is part of the URL and not part of a POST body, I would 
suggest to rather throw a NotFoundException. This way a user will just get 
notified that there are no correlationRules available for any other kind of 
policy. (Caller doesn't need to know which part of the URL is mapped to a 
parameter, thus I think not found fits better in this case.)

Please be aware of my sample above to insert a @Path annotation. Otherwise you 
will have two methods for the same URL pattern (in this case list operation). 
Of course you can also use @Path(rules) if you like to shorten URL a little 
bit. Here is a sample of how the complete URL will look like:

http://localhost:9080:/syncope/policies/sync/rules -- This will call your 
method
http://localhost:9080:/syncope/policies/password/rules -- 404 NotFound
http://localhost:9080:/syncope/policies/xyzABC/rules -- 404 NotFound
http://localhost:9080:/syncope/policies/sync/someURL -- 404 NotFound
http://localhost:9080:/syncope/policies/sync -- Returns list of available sync 
policies

 What are the best practices for this scenario?

Throw IllegalArgumentException if payload if message is corrupt 
and throw NotFoundException if URL does not match a valid useCase.

Best regards.
Jan

 Best regards,
 F.

RE: dbDump in ReportService and ConfigurationService

2013-02-06 Thread Jan Bernhardt

Hi Francesco,

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Dienstag, 5. Februar 2013 11:38
 To: dev@syncope.apache.org
 Subject: dbDump in ReportService and ConfigurationService

 Hi all,
 I am currently completing some modifications started yesterday with
 ConfigurationServiceProxy.dbExport() that will involve some refactoring on
 console's HttpResourceStream and also to core's ReportTestITCase.

 Basically, I would like to encapsulate the logic for handling streams
 (content.xml and reports in various formats) in the relevant service proxies.

 While doing this, I've just noticed that ReportSevice has

  @GET
  @Path(executions/{executionId}/dbDump)
  Response exportExecutionResult(@PathParam(executionId) Long
 executionId,
  @QueryParam(format) ReportExecExportFormat fmt);

 while ConfigurationService has

  @GET
  @Path(dbDump)
  Response dbExport();

 Any special reason for this dbDump?

No there is no special reason for dbDump. (Code looks to me, as if this is 
what happens here.) I only tried to find a consistent manner, who to title a 
downloadable stream. I'm completely open for any suggestions/improvements for a 
different URL path.

Best regards.
Jan

 The only thing I can see is that both methods return an object stream (that
 can be in some cases XML) instead of serialized instances in JSON / XML as
 the rest.

 Regards.

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: GIT mirror

2013-02-06 Thread Jan Bernhardt

+1

Best regards.
Jan

 -Original Message-
 From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
 Sent: Mittwoch, 6. Februar 2013 11:42
 To: dev@syncope.apache.org
 Subject: GIT mirror

 Hi all,

 I take it there are no objections if I go ahead and ask INFRA to create a GIT
 mirror of the Apache Syncope SVN tree?

 http://git.apache.org/
 http://wiki.apache.org/general/GitAtApache

 It doesn't have any implications beyond allowing committers to use git-svn if
 they prefer.

 Colm.

 --
 Colm O hEigeartaigh

 Talend Community Coder
 http://coders.talend.com

[jira] [Commented] (SYNCOPE-252) Update LICENSE / NOTICE files for any added or removed Maven dependency


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571138#comment-13571138
 ] 

Jan Bernhardt commented on SYNCOPE-252:
---

I could find license references in syncopes LICENSE file, for all but these:
ant-launcher-1.7.1
batik-js-1.7
c3p0-0.9.1.1
javax.ws.rs-api-2.0-m15
jaxb-impl-2.1.13
jcl-over-slf4j-1.7.2
serp-1.13.1
stax2-api-3.1.1
stax-api-1.0-2
validation-api-1.0.0.GA
wsdl4j-1.6.2
xalan-2.6.0
xml-resolver-1.2

Can someone help me to get the mapping?

I also discovered that Eclipse Public License v1.0 is referred several times 
(see above) but is not included within license file. Do we need to insert a 
copy of this license into our license file?

 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571138#comment-13571138
 ] 

Jan Bernhardt edited comment on SYNCOPE-252 at 2/5/13 8:23 AM:
---

I could find license references in syncopes LICENSE file, for all but these:
ant-launcher-1.7.1
batik-js-1.7
c3p0-0.9.1.1
javax.ws.rs-api-2.0-m15
jaxb-impl-2.1.13
jcl-over-slf4j-1.7.2
serp-1.13.1
stax-api-1.0-2
validation-api-1.0.0.GA
wsdl4j-1.6.2
xalan-2.6.0
xml-resolver-1.2

Can someone help me to get the mapping?

I also discovered that Eclipse Public License v1.0 is referred several times 
(see above) but is not included within license file. Do we need to insert a 
copy of this license into our license file?

  was (Author: jan4talend):
I could find license references in syncopes LICENSE file, for all but these:
ant-launcher-1.7.1
batik-js-1.7
c3p0-0.9.1.1
javax.ws.rs-api-2.0-m15
jaxb-impl-2.1.13
jcl-over-slf4j-1.7.2
serp-1.13.1
stax2-api-3.1.1
stax-api-1.0-2
validation-api-1.0.0.GA
wsdl4j-1.6.2
xalan-2.6.0
xml-resolver-1.2

Can someone help me to get the mapping?

I also discovered that Eclipse Public License v1.0 is referred several times 
(see above) but is not included within license file. Do we need to insert a 
copy of this license into our license file?
  
 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571154#comment-13571154
 ] 

Jan Bernhardt commented on SYNCOPE-252:
---

Thank you!
I will update license and notice file accordingly (later today)

 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571399#comment-13571399
 ] 

Jan Bernhardt commented on SYNCOPE-252:
---

OK, I added all missing license information in LICENSE file. But I'm not sure 
what to add for NOTICE file. Can someone assists?

 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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

RE: [Report] CXF migration status

2013-02-04 Thread Jan Bernhardt

Yes.

Best regards.
Jan

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Montag, 4. Februar 2013 09:16
 To: dev@syncope.apache.org
 Subject: Re: [Report] CXF migration status

 Hi all,
 a side question: will you remove the CXF experimental branch at the end of
 SYNCOPE-231 (or at the end of SYNCOPE-285)?

 Regards.

 On 02/02/2013 17:23, Francesco Chicchiriccò wrote:
  On 02/02/2013 12:07, Andrei Shakirin wrote:
  Hi,

  Would like to shortly report status of CXF migration:

  It looks very nice, thanks for reporting.

  As already said before, your (and the whole CXF team's) contribution
  has been very important and brought this project to a higher level in
  terms of activity, involvement, community growing, etc.

  I think now we just have to focus on some refinements - that will take
  some time, tough - before start discussing about releasing this
  feature-rich release 1.1.0.

  Have a nice holiday (Andrei) and WE (the rest of the crew).
  Regards.

  It is basically finished. We still have 2 Failures and 4 Errors in
  JAXRS tests - it should be fixed in next days (the reason of two is
  already clear).

  Still open for 1.1.0 (SYNCOPE -231):

  1)  Fix rest errors in tests (6)

  2)  Finishing documentation

  3)  Configure (but not activate) CXF client for console

  4)  Release Notes

  Open for 1.2.0:

  1)  Final review of REST interfaces

  2)  Clean Spring MVC interfaces, proxies and tests

  3)  Uncomment Jackson annotations for abstract types

  4)  Activate CXF client in console

  5)  Release Notes

  Cheers,
  Andrei.

  P.S: I will not be active next two weeks because of vacation. See you
  again at the end of February.

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [DISCUSS] User Service

2013-02-04 Thread Jan Bernhardt

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Freitag, 1. Februar 2013 17:45
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] User Service

 On 01/02/2013 17:32, Jan Bernhardt wrote:
  Hi Syncoper,

  I'm almost done with new REST API Service Interface documentation [1].
 Last peace missing is only User Service. Please take time to review changes to
 new Service Interfaces and let's have a discussion on this mailing-list. I 
 think
 we already discussed all general changes, but if you find something missing,
 just continue this discussion.

  I have a couple of proposals for changes in User Service Interface, which I
 would like to get your feedback for. After we all agree with User Interface I
 will update Interface and Documentation accordingly.

  1. User Controller contains 5 methods focusing on workflow activities. My
 proposal would be to move these methods to Workflow Service interface.
 We could leave business code in UserController class for 1.1.0 release and
 only change User and Workflow Service Interfaces for now, so that this
 change will only be visible to new CXF REST API.

 The WorkflowController is a general interface for managing and querying the
 workflow definitions (that can vary depending on the standard or custom
 workflow adapters you have on your own project).

 The workflow-related methods in UserController (and RoleController BTW)
 are there because they are involved in user (and role) lifecycle management.

 Given these things, I wouldn't make any movement.

OK, it still doesn't feel right to me, but of course we still can make 
refactoring's at  a later time, when we all feel a greater need to do so.

  2. There are quite some many methods capable of handling username and
 userId likewise (suspendByUsername, deleteByUsername). As far as I can
 see console does not use any of them (*byUsername). From my point of
 view, these methods are redundant (except one), since you can always get
 user id by readUser(String username) operation. My proposal would be to
 not support these methods in new interface any longer.

 The username-based methods were introduced for making more user-
 friendly the invocation of user methods, even from command line using tools
 like curl; the admin console was built before that, and hence it's using the
 former id-based methods.

 I agree that username-based are redundant, but they were introduced to
 increase the ease of use, not the efficiency.

IMHO I would not add so many convenience functions to core interface, just for 
tools like curl. Any adaptor of syncope should rather use IDs than (temporary) 
names. I think these kind of convenience functions would belong to a rich 
syncope client [SYNCOPE-150], rather than core interface.

One problem with username is, that it makes sub-resource access more difficult 
or increases potential path collisions with other resources. 

Of course we can keep these methods as they currently are, but I would still 
like to remove them.

Who else has an opinion on this matter?

  3. There are two methods (and status types) to activate an user account.
 ACTIVATE and REACTIVATE. From my point of view REACTIVATE is redundant,
 since it shouldn't matter if user was active previously or not. All that 
 matters
 is that user should be active afterwards. Therefore my proposal would be to
 remove REACTIVATE status type and also reactivate operation method.

 Activate and reactivate are differentiated at UserWorkflowAdapter level
 because they are in fact two distinct operations. This difference is then
 naturally reflected into the REST interface.

One strength of a REST is its STATELESS design [1], which brings many 
advantages IMHO. So I would still recommend to refactor our current REST 
implementation. Of course we don't need to do this for 1.1.0 release. But do 
you agree that this would be a valuable improvement and that I should create a 
JIRA issue for that?

Best regards.
Jan

[1] http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints

 Regards.

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

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console

2013-02-01 Thread Jan Bernhardt

I'm out for lunch. After I'm back, I will take car for this issue!

Best regards.
Jan

 -Original Message-
 From: Massimiliano Perrone (JIRA) [mailto:j...@apache.org]
 Sent: Freitag, 1. Februar 2013 12:21
 To: dev@syncope.apache.org
 Subject: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task
 in Console

 [ https://issues.apache.org/jira/browse/SYNCOPE-
 305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=13568672#comment-13568672 ]

 Massimiliano Perrone commented on SYNCOPE-305:
 --

 This is due to the following statement, used in TaskRestClient.createSyncTask
 and TaskRestClient.createSchedTask.
 Long id =
 Long.valueOf(response.getHeaderString(SyncopeConstants.REST_HEADER_I
 D));

 Moreover, it seems that this REST_HEADER_ID is only used in the two
 methods mentioned above: why?

  Can't create Sync or Sched Task in Console
  --

  Key: SYNCOPE-305
  URL: https://issues.apache.org/jira/browse/SYNCOPE-305
  Project: Syncope
   Issue Type: Bug
 Reporter: Colm O hEigeartaigh
  Fix For: 1.1.0

  I can't create either a Sync or Sched Task in the Console at the moment.
 Steps to reproduce:
  1) Create a new project + just launch Syncope in embedded mode using
  the test configuration
  2) Create a new Sync Task with one of the predefined Resources. You'll see
 a Wicket Error. In Console.log I see:
  Caused by: java.lang.NumberFormatException: null
  at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35]
  at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35]
  at
  org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRest
  Client.java:175) ~[TaskRestClient.class:na]

 --
 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-305) Can't create Sync or Sched Task in Console

2013-02-01 Thread Jan Bernhardt (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13568675#comment-13568675
 ] 

Jan Bernhardt commented on SYNCOPE-305:
---

I'm out for lunch. After I'm back, I will take car for this issue!

Best regards.
Jan




 Can't create Sync or Sched Task in Console
 --

 Key: SYNCOPE-305
 URL: https://issues.apache.org/jira/browse/SYNCOPE-305
 Project: Syncope
  Issue Type: Bug
Reporter: Colm O hEigeartaigh
 Fix For: 1.1.0


 I can't create either a Sync or Sched Task in the Console at the moment. 
 Steps to reproduce:
 1) Create a new project + just launch Syncope in embedded mode using the test 
 configuration
 2) Create a new Sync Task with one of the predefined Resources. You'll see a 
 Wicket Error. In Console.log I see:
 Caused by: java.lang.NumberFormatException: null
 at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35]
 at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35]
 at 
 org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRestClient.java:175)
  ~[TaskRestClient.class:na]

--
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

RE: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task in Console

2013-02-01 Thread Jan Bernhardt

OK, should be fixed now.

Best regards.
Jan

 -Original Message-
 From: Jan Bernhardt (JIRA) [mailto:j...@apache.org]
 Sent: Freitag, 1. Februar 2013 12:26
 To: dev@syncope.apache.org
 Subject: [jira] [Commented] (SYNCOPE-305) Can't create Sync or Sched Task
 in Console

 [ https://issues.apache.org/jira/browse/SYNCOPE-
 305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=13568675#comment-13568675 ]

 Jan Bernhardt commented on SYNCOPE-305:
 ---

 I'm out for lunch. After I'm back, I will take car for this issue!

 Best regards.
 Jan

  Can't create Sync or Sched Task in Console
  --

  Key: SYNCOPE-305
  URL: https://issues.apache.org/jira/browse/SYNCOPE-305
  Project: Syncope
   Issue Type: Bug
 Reporter: Colm O hEigeartaigh
  Fix For: 1.1.0

  I can't create either a Sync or Sched Task in the Console at the moment.
 Steps to reproduce:
  1) Create a new project + just launch Syncope in embedded mode using
  the test configuration
  2) Create a new Sync Task with one of the predefined Resources. You'll see
 a Wicket Error. In Console.log I see:
  Caused by: java.lang.NumberFormatException: null
  at java.lang.Long.parseLong(Long.java:375) ~[na:1.6.0_35]
  at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_35]
  at
  org.apache.syncope.console.rest.TaskRestClient.createSyncTask(TaskRest
  Client.java:175) ~[TaskRestClient.class:na]

 --
 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

[DISCUSS] User Service

2013-02-01 Thread Jan Bernhardt

Hi Syncoper,

I'm almost done with new REST API Service Interface documentation [1]. Last 
peace missing is only User Service. Please take time to review changes to new 
Service Interfaces and let's have a discussion on this mailing-list. I think we 
already discussed all general changes, but if you find something missing, just 
continue this discussion.

I have a couple of proposals for changes in User Service Interface, which I 
would like to get your feedback for. After we all agree with User Interface I 
will update Interface and Documentation accordingly.

1. User Controller contains 5 methods focusing on workflow activities. My 
proposal would be to move these methods to Workflow Service interface. We could 
leave business code in UserController class for 1.1.0 release and only change 
User and Workflow Service Interfaces for now, so that this change will only be 
visible to new CXF REST API.

2. There are quite some many methods capable of handling username and userId 
likewise (suspendByUsername, deleteByUsername). As far as I can see console 
does not use any of them (*byUsername). From my point of view, these methods 
are redundant (except one), since you can always get user id by readUser(String 
username) operation. My proposal would be to not support these methods in new 
interface any longer.

3. There are two methods (and status types) to activate an user account. 
ACTIVATE and REACTIVATE. From my point of view REACTIVATE is redundant, since 
it shouldn't matter if user was active previously or not. All that matters is 
that user should be active afterwards. Therefore my proposal would be to remove 
REACTIVATE status type and also reactivate operation method.

WDYT?

Best regards.
Jan

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

[DISCUSS] SchemaType and SchemaService

2013-01-31 Thread Jan Bernhardt

Hi Syncoper,

We know three different schema types in syncope normal Schema, derived 
Schema and virtual Schema. In Spring REST Interface these schemas are mapped 
to three different controllers which are basically doing the same thing, just 
for each type.

Therefore I only created a single SchemaService for new CXF REST Service, 
capable of handling all three kinds. To distinguish with type of Schema should 
be handled (e.g. returned for a list operation) I created a new enum SchemaType.

The topic to discuss however is, that in org.apache.syncope.common.types there 
is already a class named SchemaType containing data types for (user, role, 
membership) schema values (e.g. String, Long, Date, ...). My proposal would be 
to rename existing SchemaType class to EntitySchemaType (similar to 
EntityViolationType) and move SchemaType currently included in SchemaService 
Interface to org.apache.syncope.common.types.SchemaType.

Any objections?

Best regards.
Jan

RE: [DISCUSS] Two Jira issues for Exceptions

2013-01-31 Thread Jan Bernhardt

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 31. Januar 2013 15:58
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] Two Jira issues for Exceptions
 
 On 31/01/2013 15:54, Andrei Shakirin wrote:
  Hi,
 
  We have implemented two proposals from [1] by CXF migration.
  I am going to create Jira  issues for rest two:
 
  1)  Mapping to SyncopeClientCompositeException on client side
 
  2)  Mapping low level exceptions in core
 

+1

 Fine.
 
  and schedule them to 1.3.0?
 
 Why not 1.2.0?

+1 for 1.2.0

 
 Regards.
 
  [1]
 
 https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions
 
 --
 Francesco Chicchiriccò
 
 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: Console Resource User Mapping error

2013-01-29 Thread Jan Bernhardt

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Montag, 28. Januar 2013 17:45
 To: dev@syncope.apache.org
 Subject: Re: Console Resource User Mapping error

 On 28/01/2013 17:41, Colm O hEigeartaigh wrote:
  Apologies, for the noise, I've found the error:

  java.lang.IllegalArgumentException
   at java.net.URI.create(URI.java:841)
   at

 org.apache.syncope.client.services.proxy.ResourceServiceProxy.create(Reso
 urceServiceProxy.java:48)
   at
  org.apache.syncope.console.rest.ResourceRestClient.create(ResourceRest
  Client.java:65)

  ...

  Caused by: java.net.URISyntaxException: Illegal character in path at
  index
  51: http://localhost:9080/syncope/rest/resource/read/H2 Resource.json
   at java.net.URI$Parser.fail(URI.java:2810)

  It can't handle a space in the name of the Resource.

 Are we just missing a good old URLEncoder.encode() in
 ConnectorRestClient,java on console side?

Ups. This must have been me. 
I'll fix ServiceProxies. Discovered that same applies to 
ConfigurationServiceProxy and SchemaServiceProxy.

Reagrds.
Jan

 Regards.

  On Mon, Jan 28, 2013 at 4:37 PM, Francesco Chicchiriccò
  ilgro...@apache.org
  wrote:
  On 28/01/2013 17:32, Colm O hEigeartaigh wrote:

  Hi Francesco,

  I am creating the new Connector from scratch + adding the new
 Resource.
  Looking at core-rest.log I see the following:

  [...]

  Unless I am mistaken, it appears to be creating 5 mappings here?

  a) Username - AccountId
  b) Password - Password
  c) surname - SURNAME

  and the extra:

  d) Username - AccountId (with extAttrName=__NAME__)
  e) Password - Password (with extAttrName=__PASSWORD__)

  That's wrong, it seems like (d) and (e) are some sort of preliminary
  version of (a) and (b).

  Anyway, this should generate an error for invalid mapping, since
  there must be exactly a single AccountId per resource (and user / role).

  Is this reported in the logs? Is the mapping created on the core?

  Regards.

On Mon, Jan 28, 2013 at 4:13 PM, Francesco Chicchiriccò 
  ilgro...@apache.org

  wrote:
  On 28/01/2013 16:48, Colm O hEigeartaigh wrote:

Hi guys,
  I'm getting a strange error when adding some Resource User
  Mappings in the Console on trunk. I have a H2 backend, and I
  configure a Connector for it.
  I am adding a Username/Password/User Schema attribute mapping.
  When I try to save it, I see an Error:null on the top of the
  screen + the following error in the logs:

  15:43:51.031 ERROR
  org.apache.syncope.console.pages.AbstractBasePage
  -
  Failure managing resource org.apache.syncope.common.to.

  ResourceTO@d0bbe47.

  The weird thing is when I cancel the Resource creation it still
  appears in the table, and when I edit it again and look at the
  User mappings, I see that the Username + Password (AccountId +
  Password) mappings show up with an external attribute configured
  from the table in the backend.

  Can someone confirm this is a bug?

At least it smells like that :-)
  You should take a deeper log to both console's and core's logs to
  understand what's happening.

  Are you creating the H2 connector in the same session as the
  associated resource or is the connector pre-existing? My guess is
  that the schema() call on the connector is failing for some reason.

  Regards.

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

[jira] [Commented] (SYNCOPE-297) External Attributes are showing up for AccoundId/Password in Resource User Mappings

2013-01-29 Thread Jan Bernhardt (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565484#comment-13565484
 ] 

Jan Bernhardt commented on SYNCOPE-297:
---

Problem could be related to Internal Server Error in 
ConnInstanceController.getSchemaNames(...) Line 334 ?

I get strange exception behavior here, when using H2 connector...

 External Attributes are showing up for AccoundId/Password in Resource User 
 Mappings
 ---

 Key: SYNCOPE-297
 URL: https://issues.apache.org/jira/browse/SYNCOPE-297
 Project: Syncope
  Issue Type: Bug
Reporter: Colm O hEigeartaigh
 Fix For: 1.1.0

 Attachments: Screenshot.png


 I have a Database Connector for a H2 backend with a simple table. I am 
 creating a Resource User Mapping of Username - Account Id, Password - 
 Password, and a User schema 'surname' attribute - SURNAME column in the 
 table.
 The Resource now creates ok, however when I edit it and look at the User 
 mappings, I see that another column name 'GIVENNAME' is appearing as the 
 external attribute for the User Account Id and Password mappings.

--
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] [Updated] (SYNCOPE-292) NPE when accessing Configuration page with no global sync policy

2013-01-28 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt updated SYNCOPE-292:
--

Assignee: Jan Bernhardt

 NPE when accessing Configuration page with no global sync policy
 

 Key: SYNCOPE-292
 URL: https://issues.apache.org/jira/browse/SYNCOPE-292
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.1.0
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 As reported in ML [1], there is an issue when no global sync policy exists.
 [1] http://syncope-dev.1063484.n5.nabble.com/NPE-in-Console-tt5712327.html

--
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

RE: [jira] [Updated] (SYNCOPE-293) Modify version layout

2013-01-28 Thread Jan Bernhardt

Looks very nice. 

Textblock could need some padding.

Best regards.
Jan


 -Original Message-
 From: Massimiliano Perrone (JIRA) [mailto:j...@apache.org]
 Sent: Montag, 28. Januar 2013 12:35
 To: dev@syncope.apache.org
 Subject: [jira] [Updated] (SYNCOPE-293) Modify version layout
 
 
  [ https://issues.apache.org/jira/browse/SYNCOPE-
 293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
 
 Massimiliano Perrone updated SYNCOPE-293:
 -
 
 Attachment: Schermata.png
 
 Guys,
 do you like this?
 If it's ok, I will commit it.
 
  Modify version layout
  -
 
  Key: SYNCOPE-293
  URL: https://issues.apache.org/jira/browse/SYNCOPE-293
  Project: Syncope
   Issue Type: Improvement
   Components: console
 Reporter: Massimiliano Perrone
 Assignee: Massimiliano Perrone
  Fix For: 1.1.0
 
  Attachments: Schermata.png
 
 
  Current layout has a static labels to core and console version.
  Add a new Link to open a ModalPage with version and other project
  information (eg. link to license)
 
 --
 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] [Reopened] (SYNCOPE-292) NPE when accessing Configuration page with no global sync policy

2013-01-28 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt reopened SYNCOPE-292:
---


I agree with you Colm. If no global policy is available, it should not be 
listed as (0) policy in console.

I'll fix this as well.

 NPE when accessing Configuration page with no global sync policy
 

 Key: SYNCOPE-292
 URL: https://issues.apache.org/jira/browse/SYNCOPE-292
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.1.0
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 As reported in ML [1], there is an issue when no global sync policy exists.
 [1] http://syncope-dev.1063484.n5.nabble.com/NPE-in-Console-tt5712327.html

--
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] [Resolved] (SYNCOPE-292) NPE when accessing Configuration page with no global sync policy

2013-01-28 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt resolved SYNCOPE-292.
---

Resolution: Fixed

 NPE when accessing Configuration page with no global sync policy
 

 Key: SYNCOPE-292
 URL: https://issues.apache.org/jira/browse/SYNCOPE-292
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 1.1.0
Reporter: Francesco Chicchiriccò
Assignee: Jan Bernhardt
 Fix For: 1.1.0


 As reported in ML [1], there is an issue when no global sync policy exists.
 [1] http://syncope-dev.1063484.n5.nabble.com/NPE-in-Console-tt5712327.html

--
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] [Updated] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)

2013-01-25 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt updated SYNCOPE-231:
--

Attachment: TaskService.patch

I do not understand why this patch (TaskService) breaks 
UserTestITCase.issueSYNCOPE279() Test...

Can someone (smarter than me) support? 

 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

RE: Syncope-trunk - Build # 478 - Unstable

2013-01-24 Thread Jan Bernhardt

I'll care about this...

Best regards.
Jan


 -Original Message-
 From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
 Sent: Donnerstag, 24. Januar 2013 09:29
 To: dev@syncope.apache.org; Jan Bernhardt; ilgro...@apache.org
 Subject: Syncope-trunk - Build # 478 - Unstable
 
 The Apache Jenkins build system has built Syncope-trunk (build #478)
 
 Status: Unstable
 
 Check console output at https://builds.apache.org/job/Syncope-trunk/478/
 to view the results.

RE: Open Wiki pages for CXF migration

2013-01-24 Thread Jan Bernhardt

+1

Best regards.
Jan

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 24. Januar 2013 12:40
 To: dev@syncope.apache.org
 Subject: Re: Open Wiki pages for CXF migration

 On 23/01/2013 15:33, Christian Schneider wrote:
  Hi Syncopers,

  the wiki pages about the rest api and the exception concept are
  currently protected. I can not access them and as Francesco reported
  some time ago we can not directly edit the group that protects the page.
  So I propose to open these pages for the public and simply have a
  disclaimer that this is work in progress.

  See:
  https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade

 Agree: If no one has objections, I would unlock access to that wiki page (and
 its children) + add a disclaimer.

 Regards.

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [VOTE] Apache Syncope 1.0.5

2013-01-24 Thread Jan Bernhardt

+1

Best regards.
Jan

 -Original Message-
 From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
 Sent: Mittwoch, 23. Januar 2013 19:25
 To: dev@syncope.apache.org
 Subject: [VOTE] Apache Syncope 1.0.5
 
 Hi All, I've created a 1.0.5 release, with the following artifacts up for a 
 vote:
 
 SVN source tag (r1437608):
 https://svn.apache.org/repos/asf/syncope/tags/syncope-1.0.5/
 
 List of changes:
 https://svn.apache.org/repos/asf/syncope/tags/syncope-1.0.5/CHANGES
 
 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachesyncope-167/
 
 Source release (checksums and signatures are available at the same
 location):
 https://repository.apache.org/content/repositories/orgapachesyncope-
 167/org/apache/syncope/syncope-root/1.0.5/syncope-root-1.0.5-source-
 release.zip
 
 Staging site:
 http://syncope.apache.org/1.0.5/
 
 PGP release keys (signed using B1F055C1):
 http://www.apache.org/dist/syncope/KEYS
 
 Vote will be open for 72 hours.
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

2013-01-23 Thread Jan Bernhardt

 -Original Message-
 From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
 Sent: Mittwoch, 23. Januar 2013 10:29
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] New REST Service Interfaces - ConfigurationService

 Il giorno 23/gen/2013, alle ore 09.54, Francesco Chicchiriccò ha scritto:

  On 23/01/2013 09:06, Jan Bernhardt wrote:
  Hi Syncoper,

  here are the proposed changes for our Configuration Service:

  * Changing Create response type to javax.ws.rs.core.Response. This way
 we can set response HTTP Status code (201 created) without requiring
 HttpServletResponse as method parameter. Also according to best RESTful
 practices instead of returning newly created object directly, only URL for new
 Object (Configuration) will be returned. Console does not even care about
 created response, thus network traffic can be reduced, by not sending
 object (configuration). If consumer does care about new object he can easily
 follow provided URL (in response) and retrieve new object.

  If this is a REST best practice, fine for me.

  * Changed ModelAndView response type to SetValidatorTO /
 SetMailTemplateTO and introduced wrapper TO classes for ValidatorTO
 and MailTemplateTO.

  Fine.

  * Changed return type from update() and delete()  to void, since console
 does not even care about it, and I think this should be best practice anyway,
 since consumer knows updates object already and does not care about
 deleted ones, therefore there is no need to send them over the network.

  About update() I can agree with you: since the updated entity (user, role,
 ...) is still there, an URL can be returned as in the create() case reported
 above.

Technically it would be no problem to return such a URL, but I don't see much 
value in doing this. Update operations are performed with a PUT Operation. You 
can use the same URL with a GET Operation to retrieve updated object. This 
behavior has changed to URL pattern of Spring REST services, where there was a 
*/read/* and */update/* path. With CXF Services I focused on using matching 
HTTP operations as this also applies to RESTful best practices.

  About delete() however, not retuning the deleted entity can break the
 current feature: once again, please don't think that the admin console is the
 only REST client out there.

Old (Spring) REST API will not be changed. New CXF URLs in most cases will not 
match old URLs (see read, update, delete behavior mentioned above), so clients 
would have to be updated anyway. And I don't see a problem for a client to 
first make a GET call an a resource and then following a DELETE call, if he is 
interested in deleted resource. (which I expect not to be the case most often).

 +1
 The response provided by the delete is also used to know the outcome of
 the deletion performed onto the external resources.

I agree with you for Roles and Users since changes will be propagated to other 
systems. But all other resources in Syncope are only internal in Core. 
Therefore I would suggest to not return anything for delete operation except 
for users and roles.

Best regards.
Jan

  Regards.

  --
  Francesco Chicchiriccò

  ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
  http://people.apache.org/~ilgrosso/

RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

2013-01-23 Thread Jan Bernhardt

 -Original Message-
 From: Andrei Shakirin [mailto:ashaki...@talend.com]
 Sent: Mittwoch, 23. Januar 2013 10:38
 To: dev@syncope.apache.org
 Subject: RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

 Hi,

  I generally agree with the concept of returning created with the
  location in create methods. The problem is though that our service
  interface has no method to get the object based on the location.

 Pragmatic solution is returning URI as well as business object ID in Response
 object.
 In that case we avoid building URI / extracting ID from URI manually.

+1
URL Location in Response header (as usual) and ResourceID (Long or String) in 
HTTP response body.

 Cheers,
 Andrei.

  -Original Message-
  From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf
  Of Christian Schneider
  Sent: Mittwoch, 23. Januar 2013 10:01
  To: dev@syncope.apache.org
  Subject: Re: [DISCUSS] New REST Service Interfaces -
  ConfigurationService

  Hi Jan,

  I generally agree with the concept of returning created with the
  location in create methods. The problem is though that our service
  interface has no method to get the object based on the location.
  So we either have to change our client and interface to work with
  resource uris instead of ids or we have to return the id of the object
  in the create method. So perhaps we can return the location for true
  restful clients and the id in the entity of the response for people using 
  the
 interface.

  Christian

  On 23.01.2013 09:06, Jan Bernhardt wrote:
   Hi Syncoper,

   here are the proposed changes for our Configuration Service:

   * Changing Create response type to javax.ws.rs.core.Response. This
   way
  we can set response HTTP Status code (201 created) without requiring
  HttpServletResponse as method parameter. Also according to best
  RESTful practices instead of returning newly created object directly,
  only URL for new Object (Configuration) will be returned. Console does
  not even care about created response, thus network traffic can be
  reduced, by not sending object (configuration). If consumer does care
  about new object he can easily follow provided URL (in response) and
 retrieve new object.

   * Changed ModelAndView response type to SetValidatorTO /
  SetMailTemplateTO and introduced wrapper TO classes for ValidatorTO
  and MailTemplateTO.

   * Changed return type from update() and delete()  to void, since
   console
  does not even care about it, and I think this should be best practice
  anyway, since consumer knows updates object already and does not care
  about deleted ones, therefore there is no need to send them over the
 network.

   Any objections?

   Best regards.
   Jan

RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

2013-01-23 Thread Jan Bernhardt

 -Original Message-
 From: Andrei Shakirin [mailto:ashaki...@talend.com]
 Sent: Mittwoch, 23. Januar 2013 10:45
 To: dev@syncope.apache.org
 Subject: RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

  +1
  URL Location in Response header (as usual) and ResourceID (Long or
  String) in HTTP response body.

 I would even put ResourceID to HTTP header as well.
 It is relative small and is kind of object metadata - that corresponds HTTP
 Header spec.

Agree.

 Cheers,
 Andrei.

  -Original Message-
  From: Jan Bernhardt [mailto:jbernha...@talend.com]
  Sent: Mittwoch, 23. Januar 2013 10:41
  To: dev@syncope.apache.org
  Subject: RE: [DISCUSS] New REST Service Interfaces -
  ConfigurationService

   -Original Message-
   From: Andrei Shakirin [mailto:ashaki...@talend.com]
   Sent: Mittwoch, 23. Januar 2013 10:38
   To: dev@syncope.apache.org
   Subject: RE: [DISCUSS] New REST Service Interfaces -
   ConfigurationService

   Hi,

I generally agree with the concept of returning created with the
location in create methods. The problem is though that our service
interface has no method to get the object based on the location.

   Pragmatic solution is returning URI as well as business object ID in
   Response object.
   In that case we avoid building URI / extracting ID from URI manually.

  +1
  URL Location in Response header (as usual) and ResourceID (Long or
  String) in HTTP response body.

   Cheers,
   Andrei.

-Original Message-
From: Christian Schneider [mailto:cschneider...@gmail.com] On
Behalf Of Christian Schneider
Sent: Mittwoch, 23. Januar 2013 10:01
To: dev@syncope.apache.org
Subject: Re: [DISCUSS] New REST Service Interfaces -
ConfigurationService

Hi Jan,

I generally agree with the concept of returning created with the
location in create methods. The problem is though that our service
interface has no method to get the object based on the location.
So we either have to change our client and interface to work with
resource uris instead of ids or we have to return the id of the
object in the create method. So perhaps we can return the location
for true restful clients and the id in the entity of the response
for people using the
   interface.

Christian

On 23.01.2013 09:06, Jan Bernhardt wrote:
 Hi Syncoper,

 here are the proposed changes for our Configuration Service:

 * Changing Create response type to javax.ws.rs.core.Response.
 This way
we can set response HTTP Status code (201 created) without
requiring HttpServletResponse as method parameter. Also according
to best RESTful practices instead of returning newly created
object directly, only URL for new Object (Configuration) will be
 returned.
Console does not even care about created response, thus network
traffic can be reduced, by not sending object (configuration). If
consumer does care about new object he can easily follow provided
URL (in response) and
   retrieve new object.

 * Changed ModelAndView response type to SetValidatorTO /
SetMailTemplateTO and introduced wrapper TO classes for
ValidatorTO and MailTemplateTO.

 * Changed return type from update() and delete()  to void, since
 console
does not even care about it, and I think this should be best
practice anyway, since consumer knows updates object already and
does not care about deleted ones, therefore there is no need to
send them over the
   network.

 Any objections?

 Best regards.
 Jan

RE: [DISCUSS] New REST Service Interfaces - ConfigurationService

2013-01-23 Thread Jan Bernhardt

 -Original Message-
 From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
 Sent: Mittwoch, 23. Januar 2013 10:52
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] New REST Service Interfaces - ConfigurationService

 Hi Jan
 On 23/01/13 08:06, Jan Bernhardt wrote:
  Hi Syncoper,

  here are the proposed changes for our Configuration Service:

  * Changing Create response type to javax.ws.rs.core.Response. This way
 we can set response HTTP Status code (201 created) without requiring
 HttpServletResponse as method parameter. Also according to best RESTful
 practices instead of returning newly created object directly, only URL for new
 Object (Configuration) will be returned. Console does not even care about
 created response, thus network traffic can be reduced, by not sending
 object (configuration). If consumer does care about new object he can easily
 follow provided URL (in response) and retrieve new object.

 I think it is fine echoing back the created resource representation (alongside
 Location) when it can help the client to avoid the extra round trip, I guess 
 it
 depends on the actual requirements of the console client

I would think that for roles and users it would be best to directly responding 
created objects since they contain propagation information. 
For all other resources our console does not even care about, so there is no 
need to directly respond them. 
If other consoles do care, they can follow the provided URL or call interface 
read operation with provided ID (from response header).

  * Changed ModelAndView response type to SetValidatorTO  /
 SetMailTemplateTO  and introduced wrapper TO classes for ValidatorTO
 and MailTemplateTO.

 One thing I should mention is that auto-describing the explicit collections is
 tricky in WADL, though of course one can register a custom WADL document
 with CXF; personally I prefer using collection wrapper beans - it is simpler 
 to
 get them described and also easier to attach some more metadata to such
 collection in the form of the wrapper properties, that said, returning the
 explicit collections will also work

Interesting point. Thanks for this feedback Sergey. I currently do not see any 
need for additional metadata, so I would rather want to avoid additional 
refactoring work, even thou I think using a WrapperClass would be a better 
interface design.
Do you expect this WADL generation problem to remain for a long time? I would 
rather not want to change my interface design due to a temporal missing feature 
of another component...

Best regards.
Jan

 Cheers, Sergey

  * Changed return type from update() and delete()  to void, since console
 does not even care about it, and I think this should be best practice anyway,
 since consumer knows updates object already and does not care about
 deleted ones, therefore there is no need to send them over the network.

  Any objections?

  Best regards.
  Jan

  -Original Message-
  From: Jan Bernhardt [mailto:jbernha...@talend.com]
  Sent: Donnerstag, 17. Januar 2013 14:04
  To: dev@syncope.apache.org
  Subject: RE: [Discussion] New REST Service Interfaces - Entitlements

  Hi Syncoper,

  The following changes are proposed regarding  AuthenticationController:

  === Renaming Service ===
  Rename AuthenticationController to EntitlementService(Impl), since
  containing methods have little to nothing to do with authentication.
  It is only about Entitlements...

  === Changing response Type ===
  listEntitlements() returns a ListString  whereas getEntitlements()
  returns a SetString.

   From my point of view both methods should return a SET since
  entitlements have no order and cannot exists or be assigned more than
 once.

  Due to some JAX-B / JAX-RS limitations, it is not possible to return
  a collection with primitive data types in java. A wrapper class is 
  required,
 e.g.
  SetEntitlementTO.

  EntitlementTO can be modeled in one of two ways:

  Option 1:
  EntitlementTOs
  EntitlementTOROLE_ADMIN/EntitlementTO
  EntitlementTOROLE_SUPERUSER/EntitlementTO
  /EntitlementTOs

  Option 2:
  EntitlementTOs
  EntitlementTO
 nameROLE_ADMIN/name
 /EntitlementTO
  EntitlementTO
 name  ROLE_SUPERUSER/name
 /EntitlementTO
  /EntitlementTOs

  Option 1 matches more or less current marshaling. I personally would
  prefer Option 2 because this would give us the opportunity to easily
  extend EntitlementTO at a later point (if needed) without becoming
  incompatible with previous version.

  WDYT?

  All of these changes will not apply to current Spring
  Controller/Services, but only future CXF REST Service. So
  AuthenticationController will not be renamed now, and responsetype of
  AuthenticationController will not change. Changes only apply for new
  Service Interface and (Proxy) Implementation.

  Best regards.
  Jan

RE: [DISCUSS] Moving issues from one version to another

2013-01-23 Thread Jan Bernhardt

Thanks!

Best regards.
Jan

 -Original Message-
 From: ilgrosso [mailto:ilgro...@apache.org]
 Sent: Mittwoch, 23. Januar 2013 11:28
 To: dev@syncope.apache.org
 Subject: Re: [DISCUSS] Moving issues from one version to another

 Hi all,
 as discussed before in this thread, I've just moved / created issues in JIRA
 and updated the roadmap wiki page.

 Let's focus on releasing this 1.1.0 as soon as possible, now.

 Regards.

 --
 View this message in context: http://syncope-
 dev.1063484.n5.nabble.com/DISCUSS-Moving-issues-from-one-version-to-
 another-tp5712048p5712157.html
 Sent from the syncope-dev mailing list archive at Nabble.com.

RE: [Question] Trunk build problem (archetype)

2013-01-23 Thread Jan Bernhardt

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Mittwoch, 23. Januar 2013 13:18
 To: dev@syncope.apache.org
 Subject: Re: [Question] Trunk build problem (archetype)

 On 23/01/2013 13:13, Francesco Chicchiriccò wrote:
  On 23/01/2013 13:07, Jan Bernhardt wrote:
  Hi,

  I have the same problem since last update with building trunk.

  I have just tried from a fresh checkout of trunk with mvn clean
  install on Linux: no problems.

  Shall I try on Windows?

 Just done: problem confirmed, I'll fix it right away...

 Regards.

 P.S. why don't you just perform an upgrade an install Linux on your laptop?
 Just joking... :-P

This would be too easy for me ;-)

And since our Windows Jenkins build is not running, I think it is good to have 
developers build and test on different platforms.

Best regards.
Jan

  -Original Message-
  From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
  Sent: Mittwoch, 23. Januar 2013 12:22
  To: dev@syncope.apache.org
  Subject: Re: [Question] Trunk build problem (archetype)

  On 23/01/2013 12:13, Andrei Shakirin wrote:
  Hi,

  I am currently cannot build archetype (Apache Syncope sample
  project)
  from trunk with an error:
  [INFO] [ERROR] Unknown lifecycle phase #. You must specify a
  valid
  lifecycle ...
  I see the similar problem in Jenkins build for 1_0_X branch, but
  not for the
  trunk.

  The latest build problem with 1_0_X was fixed [1]

  Are you experiencing build problems with a new project generated
  from the 1.1.0-SNAPSHOT archetype or in building trunk
  (1.1.0-SNAPSHOT) sources?

  Has anybody clue how to fix it?
  [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-
  1_0_X/116/

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [Question] ApplicationContextProvider in UnitTests

2013-01-22 Thread Jan Bernhardt

 -Original Message-
 From: Jan Bernhardt [mailto:jbernha...@talend.com]
 Sent: Montag, 21. Januar 2013 17:50
 To: dev@syncope.apache.org
 Subject: RE: [Question] ApplicationContextProvider in UnitTests

   Hi,

   Since last SVN update, I cannot build syncope on my system, due to
  never ending UnitTests.
   Which update? Was this incorporated in latest Jenkins build? [1]
   I guess my problems are related to:

   Revision 1436375 by ilgrosso:
   [SYNCOPE-249] core: extension for propagation implemented

  Hum, strange: this change was incorporated in [1] by Jenkins.

 Really strange... I had to revert all changes from today, to be able building
 syncope again...

Today I even got MaxPermGenSize errors for old revision (1435892) and Surefire 
plugin terminates my VM...

After adding @Ignore to org.apache,syncope.core.rest.data.ResourceDataTest I 
was able to build trunk version again...
All this is very strange. Not sure if this is because of a Java VM update? I'm 
using Java version: 1.6.0_25, vendor: Sun Microsystems Inc. on Windows 7 64 bit

Andrei told me yesterday that he was having similar problems (at this time I 
was still able to build syncope without any problems)... Anyone else?

Are we able to get the windows test running on Jenkins [1] again, or do we need 
to talk to infrastructure? It looks like that this project still tries to work 
with incubator SVN URL [2].

Best regards.
Jan

[1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-windows/
[2] ERROR: Failed to update 
http://svn.apache.org/repos/asf/incubator/syncope/trunk

 I'll investigate into this issue more by tomorrow.

 Regards.
 Jan

   Since I'm having problems with persistence tests. I will try to
   checkout
  earlier version and see if I can build this one.

   While trying to investigate into this issue, I tried to run unit
   test in my
  eclipse IDE. Most test are ok, but some fail due to a NullpointerException.

   This exception is caused because
   ApplicationContextProvider.getApplicationContext() is null.
   Analysing spring config and code, I cannot see/understand where/who
   is the ApplicationContextProvider.ctx initialized?
   Any help is very welcome, as well as a feedback, if you can still
   make
  clean install without problems?
   ApplicationContextProvider is initialized after Spring context set
   up since it implements ApplicationContextAware.
   Understood. Thanks.

   Best regards.
   Jan

   [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-
   trunk/464/

  --
  Francesco Chicchiriccò

  ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
  http://people.apache.org/~ilgrosso/

[jira] [Updated] (SYNCOPE-256) Update Rest exception mapper to Apache CXF


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt updated SYNCOPE-256:
--

Assignee: Andrei Shakirin  (was: Jan Bernhardt)

 Update Rest exception mapper to Apache CXF
 --

 Key: SYNCOPE-256
 URL: https://issues.apache.org/jira/browse/SYNCOPE-256
 Project: Syncope
  Issue Type: Sub-task
  Components: client, core
 Environment: CXF branch
Reporter: Andrei Shakirin
Assignee: Andrei Shakirin
 Fix For: 1.2.0

 Attachments: ExceptionMapper.patch, ExceptionMapperService.patch, 
 ExceptionMapperUserTests.patch, syncopeClientError.jsp.patch, 
 Unauthorized.patch


 Spring exception mapper is replaced to CXF one and configured as provider in 
 rest endpoint and client.
 Converting of exceptions to HTTP error codes on service side is also done by 
 exception mapper.

--
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-246) Remove collection setters in transfer objects for JAXB marshalling

[
https://issues.apache.org/jira/browse/SYNCOPE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559499#comment-13559499
]

Jan Bernhardt commented on SYNCOPE-246:
---

Christian Schneider is currently investigating if it would be possible to keep
setter for 1.1.0 release but without clearing collections.

Remove collection setters in transfer objects for JAXB marshalling
--

Key: SYNCOPE-246
URL: https://issues.apache.org/jira/browse/SYNCOPE-246
Project: Syncope
Issue Type: Sub-task
Components: core
Affects Versions: 1.1.0
Environment: CXF branch
Reporter: Andrei Shakirin
Assignee: Jan Bernhardt
Fix For: 1.2.0

XML payload will be marshaled/unmarshaled using JAXB by migration to CXF Rest
frontend.
JAXB works with collections in a little bit different way as Spring Rest
marshaling.
JAXB uses only getter for the list (assumes that list is initialized due
object creation) and adds elements into the list obtained by getter by
unmarshaling. It doesn't need setter at all.
The problem is that actual implementation of transfer objects doesn't work
with JAXB.
If TO provide setter for collection, JAXB gets the list, adds the elements
and additionally calls setter for this list. As far as setter logic cleans
the TO collection, the result collection is always empty.
Solution is remove setters for collections in TOs by migration on CXF Rest.
I find it also better from security and encapsulation aspects.
Regards,
Andrei.

--
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] [Updated] (SYNCOPE-246) Remove collection setters in transfer objects for JAXB marshalling

[
https://issues.apache.org/jira/browse/SYNCOPE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jan Bernhardt updated SYNCOPE-246:
--

Assignee: Christian Schneider (was: Jan Bernhardt)

Remove collection setters in transfer objects for JAXB marshalling
--

[jira] [Updated] (SYNCOPE-246) Remove collection setters in transfer objects for JAXB marshalling

[
https://issues.apache.org/jira/browse/SYNCOPE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jan Bernhardt updated SYNCOPE-246:
--

Fix Version/s: (was: 1.2.0)
1.1.0

Remove collection setters in transfer objects for JAXB marshalling
--

[jira] [Commented] (SYNCOPE-281) Refactor client module: Move common classes into common module

2013-01-21 Thread Jan Bernhardt (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558664#comment-13558664
 ] 

Jan Bernhardt commented on SYNCOPE-281:
---

OK, makes sense. I very happy to see, that syncope has sees kind of tests! For 
some reasons I do not know currently, I get problems starting my firefox during 
Selenium tests. I will try to investigate into it...

I also fixed ReportTestITCase.

 Refactor client module: Move common classes into common module
 --

 Key: SYNCOPE-281
 URL: https://issues.apache.org/jira/browse/SYNCOPE-281
 Project: Syncope
  Issue Type: Improvement
  Components: client, common, core
Reporter: Jan Bernhardt
Assignee: Jan Bernhardt
  Labels: refactoring
 Fix For: 1.1.0


 Currently a lot of common classes are inside client module. These classes 
 are needed for both client and server side. Goal of this issue is to 
 introduce a new common module which contains all classes needed on both 
 sides, client and server.

--
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

RE: [Question] ApplicationContextProvider in UnitTests

2013-01-21 Thread Jan Bernhardt

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Montag, 21. Januar 2013 17:14
 To: dev@syncope.apache.org
 Subject: Re: [Question] ApplicationContextProvider in UnitTests

 On 21/01/2013 17:07, Jan Bernhardt wrote:
  Hi,

  Since last SVN update, I cannot build syncope on my system, due to never
 ending UnitTests.

 Which update? Was this incorporated in latest Jenkins build? [1]

I guess my problems are related to:

Revision 1436375 by ilgrosso:
[SYNCOPE-249] core: extension for propagation implemented

Since I'm having problems with persistence tests. I will try to checkout 
earlier version and see if I can build this one.

  While trying to investigate into this issue, I tried to run unit test in my
 eclipse IDE. Most test are ok, but some fail due to a NullpointerException.
  This exception is caused because
 ApplicationContextProvider.getApplicationContext() is null. Analysing
 spring config and code, I cannot see/understand where/who is the
 ApplicationContextProvider.ctx initialized?

  Any help is very welcome, as well as a feedback, if you can still make clean
 install without problems?

 ApplicationContextProvider is initialized after Spring context set up since it
 implements ApplicationContextAware.

Understood. Thanks.

Best regards.
Jan

 Regards.

 [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-
 trunk/464/

 --
 Francesco Chicchiriccò

 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [Question] ApplicationContextProvider in UnitTests

2013-01-21 Thread Jan Bernhardt

  Hi,
 
  Since last SVN update, I cannot build syncope on my system, due to
 never ending UnitTests.
  Which update? Was this incorporated in latest Jenkins build? [1]
  I guess my problems are related to:
 
  Revision 1436375 by ilgrosso:
  [SYNCOPE-249] core: extension for propagation implemented
 
 Hum, strange: this change was incorporated in [1] by Jenkins.

Really strange... I had to revert all changes from today, to be able building 
syncope again...

I'll investigate into this issue more by tomorrow.

Regards.
Jan

 
  Since I'm having problems with persistence tests. I will try to checkout
 earlier version and see if I can build this one.
 
  While trying to investigate into this issue, I tried to run unit test in 
  my
 eclipse IDE. Most test are ok, but some fail due to a NullpointerException.
 
  This exception is caused because
  ApplicationContextProvider.getApplicationContext() is null.
  Analysing spring config and code, I cannot see/understand where/who
  is the ApplicationContextProvider.ctx initialized?
  Any help is very welcome, as well as a feedback, if you can still make
 clean install without problems?
  ApplicationContextProvider is initialized after Spring context set up
  since it implements ApplicationContextAware.
  Understood. Thanks.
 
  Best regards.
  Jan
 
  [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-
  trunk/464/
 
 --
 Francesco Chicchiriccò
 
 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~ilgrosso/

RE: [Discussion] New REST Service Interfaces - Entitlements

2013-01-18 Thread Jan Bernhardt

Hi Andrei, 

 
  === Renaming Service ===
  Rename AuthenticationController to EntitlementService(Impl), since
  containing methods have little to nothing to do with authentication.
  It is only about Entitlements...
 
 +1 for Entitlement, -1 for Service. I would keep names consistently, if use
 EntitlementService name, than rename all controllers to services inclusive
 package name (but I suggest to do it on the later phase).

Names will be Consistent. New CXF REST Services will all End with *Service. Old 
Spring Services currently ending with *Controller will eventually all vanish, 
once new Services are actually used (migration is complete).

Best regards.
Jan

RE: [Discussion] CXF migration (branches)

2013-01-18 Thread Jan Bernhardt

Hi Francesco,

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 17. Januar 2013 17:47
 To: dev@syncope.apache.org
 Subject: Re: [Discussion] CXF migration (branches)

 On 17/01/2013 10:54, Jan Bernhardt wrote:
  Hi Francesco,
  [...]
  If, as it seems there is no other way out, I'd propose to move back
  the CXF migration to 1.1.0 (as actually OSGi is still there) so that
  no additional branch is created. This is valid as long as Spring MVC
  interfaces are still working as now, as you said above.
  Yes, Spring MVC interfaces will not be affected.

 Fine, as written elsewhere by Andrei in this mail thread it seems we
 have agreed about it: would you please adjust JIRA issues accordingly?

I will take care of this.

 Ok then why not introducing this new common maven submodule (as said
 in the past) with root package org.apache.syncope.common and then start
 moving away packages from client?

+1 

Supposed that no one disagrees, I will create a Jira ticket for this task and 
take care of this. Since this refactoring will effect most classes. I would do 
this Monday morning. So all committers could use the time until Sunday to get 
their changes committed and thus avoiding a bigger merging effort after this 
refactoring.

But rather than introducing a new module I would like to rename client module 
to common (including client to common in package names).
When I did my CXF PoC (see CXF branch), I noticed that all packages except for 
org.apache.syncope.client.http are needed in common.
Syncope-150 will introduce a rich client library. My proposal would be to move 
org.apache.syncope.client.http to console, since 
org.apache.syncope.console.rest is in console and also rich client related. 
Once we take care of Syncope-150 we can (re)create a client module and then 
move both packages to this module.

Does this sound reasonable?

Best regards.
Jan

 Regards.

  -Original Message-
  From: Christian Schneider [mailto:cschneider...@gmail.com] On
 Behalf
  Of Christian Schneider
  Sent: Mittwoch, 16. Januar 2013 18:48
  To: dev@syncope.apache.org
  Subject: Re: [Discussion] CXF migration (branches)

  Jan contacted me that the E-Mail Server in the Bonn office is
  currently down so he can not reply himself at the moment.

  So I am replying what he wrote me via Skype:
  We currently have the plan to finish the CXF migration during the
  next
  1.5 weeks with 4 developers. The issue is a little urgent as from
  february on our normal product development team would like to take
  over and focus on making Syncope work nicely in OSGi. At this point
  we should have finished the CXF migration. Of course we can delay
  things a little but not too much without affecting our whole planning.

  Christian

  On 16.01.2013 16:08, Francesco Chicchiriccò wrote:
  On 16/01/2013 15:50, Jan Bernhardt wrote:
  Hi Syncopers,

  all preparation tasks are more or less done for CXF migration, so
  next we would like to start with actual CXF migration.

  Since we are planning to release Syncope 1.1.0 soon I can see two
  reasonable solutions to continue.

  1.   Creating a release branch for 1.1.0 and making sure this
  branch is stable and give it some time for additional test before
  official stable release will take place. CXF migration would
  start directly in trunk.

  2.   Creating a CXF branch and continue working on trunk for
  1.1.0 release.

  I would prefer option 1 best. I think having a release branch prior
  to office release is a good practice in general.
  I expect quite some refactoring during CXF migration (which is not
  mandatory in all cases but expedient), for example renaming some
  packages (removing client from Types, TOs, ... since they are
  rather common classes used on server and client site than specific
  only to the client) and I would also like to rename *Controller
  classes to *ServiceImpl since these classes do not act as
  controller for a workflow or GUI but rather offer some REST
  services. SVN has some limitations to handle renamed files when it
  comes to merging updates.
  Thus it could be quite painful to keep a cxf branch in sync with trunk.

  WDYT? Could we start a release branch?
  Hi Jan,
  I generally agree with (1) even though I am not sure whether Syncope
  1.1.0 release can actually happen soon: there is still a
  considerable number of issues to be solved (~20) and many changes
  introduced by
  SYNCOPE-241 SYNCOPE-259 SYNCOPE-268 (all still open) need to
  consolidate a bit.

From the other side, 46+ issues have already been resolved in 1.1.0
  and this would instead suggest pushing 1.1.0 for releasing soon.

  Finally, please consider that even with option (1) there will be
  some bugfixing in the 1_1_X branch (i.e. the current trunk) for long
  time; this will push a consistent and constant merge work to be done
  between 1_1_X and new trunk.

  Given this situation, I would

RE: [Discussion] New REST Service Interfaces - Entitlements

2013-01-18 Thread Jan Bernhardt

 
 Btw. I would rather name the xml element Entitlement than EntitlementTO
 as the fact that it is a transfer object is not important on the xml level.
 

I agree. Not using *TO ending would look nicer on transport layer. 
The question here is, should we also remove TO in Classnames, or just set a 
name in annotation, e.g. @XMLRootElement(name = entitlement) ?

 Christian

[jira] [Updated] (SYNCOPE-268) Enable Rest IntegrationTests to run more than once (per build)

2013-01-18 Thread Jan Bernhardt (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt updated SYNCOPE-268:
--

Assignee: Andrei Shakirin  (was: Jan Bernhardt)

 Enable Rest IntegrationTests to run more than once (per build)
 --

 Key: SYNCOPE-268
 URL: https://issues.apache.org/jira/browse/SYNCOPE-268
 Project: Syncope
  Issue Type: Improvement
  Components: core
Reporter: Jan Bernhardt
Assignee: Andrei Shakirin
  Labels: test
 Fix For: 1.1.0

 Attachments: RerunnableRestIntegrationTests-1.patch, 
 RerunnableRestIntegrationTests-2.patch


 Currently many Rest IntegrationTests can run only once. If you try to rerun 
 some Tests they will fail, due to the fact, that a resource with the same 
 same already exists, or that a resource was deleted previously and is not 
 available any longer. This works fine for mvn clean verify since all test 
 run exactly once. But for development phase this is inconvenient, because 
 while testing new features or other refactorings, one would like to run tests 
 several times (especially if they fail), without the need to 
 rebuild/package/deploy the whole core module.
 Tasks of this JIRA ticket is to use random identifier for resources (user, 
 role, ...) to avoid collisions, when running tests multiple times. In some 
 cases it will also be preferable to use a try { } final { } statement to 
 cleanup previously created resources.

--
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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency

2013-01-18 Thread Jan Bernhardt (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557214#comment-13557214
 ] 

Jan Bernhardt commented on SYNCOPE-252:
---

I decided to use Jackson instead of Jettision, as this was used also by spring 
object mapper. So I only had to add Apache CXF dependencies. 
Hence I would expect that this task can be closed without making any changes to 
Licence and Notice. Am I correct, or do I need to check every cxf artifact for 
embedded components with different licenses ?

 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
 Fix For: 1.2.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency

2013-01-18 Thread Jan Bernhardt (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557253#comment-13557253
 ] 

Jan Bernhardt commented on SYNCOPE-252:
---

Yes, you are right, javax.ws.rs:javax.ws.rs-api:2.0-m15 was also added 
previously. I just checked the lib file which does not contain any LICENSE or 
NOTICE file.

Since handling license issues is a rather new topic to me, what do I need to do 
here? Is a LICENSE / NOTICE not required here, since it is a javax package?

And yes, no other 3rd party code was needed / added for CXF migration.

 Update LICENSE / NOTICE files for any added or removed Maven dependency
 ---

 Key: SYNCOPE-252
 URL: https://issues.apache.org/jira/browse/SYNCOPE-252
 Project: Syncope
  Issue Type: Sub-task
  Components: console, core
Reporter: Francesco Chicchiriccò
 Fix For: 1.2.0


 If you are adding (or removing) any non-ASF dependency, please take also care 
 of LICENSE and NOTICE content either at root (included in source and JAR 
 release files) and under legal_ext (for WAR and ZIP release files).

--
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

RE: [Discussion] CXF migration (branches)

2013-01-17 Thread Jan Bernhardt

Hi Francesco, 

 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 17. Januar 2013 10:05
 To: dev@syncope.apache.org
 Subject: Re: [Discussion] CXF migration (branches)

 On 17/01/2013 09:13, Jan Bernhardt wrote:
  Hi syncoper,

  Our mail system is working again :)

 Nice: next time please also consider Nabble [1] to post to this ML - only
 remember to register with the same e-mail address you are subscribed to
 dev@.

This is what I did yesterday, but unfortunately I could also not receive the 
confirmation mail from nabble...

  As Christian already stated, we have 4 developers currently with time 
 budged to get the CXF migration done. We cannot delay this task without
 massive re-planning time constrains...

 Sorry Jan, I don't think this fact is inline with community-driven 
 development.

I don't see a conflict with community-driven development. The community can 
provide new features and extensions in topics they have a special interest and 
skillset in. Of course including these new features in a release (or trunk) 
needs to be aligned with other community members. But I think it is rather 
common that companies get engaged in Apache projects and that they focus on 
providing some extensions they need in their business. As long as the community 
agrees that these features are valuable; I don't see a problem here.

 This community discussed and established a roadmap with some releases
 [2]: this roadmap can be reviewed over time, of course, but it remains the
 driver for this project's activities, indeed.

 In the roadmap, the release 1.1.0 comes *before* 1.2.0, and we have
 currently agreed to proceed to the final CXF migration in the latter.
 Unfortunately, however, there is still plenty of issues to be closed for 
 1.1.0.

 I am personally happy that people is interested in making Syncope working
 with CXF and OSGi but I am sincerely worried of the fact that the actual core
 features - i.e. what Syncope does, not how it communicates with external or
 how it is deployed - and related documentation are left behind.

 I am also worried about the sentence reported by Christian below: We
 currently have the plan to finish the CXF migration during the next 1.5 weeks
 with 4 developers.  The issue is a little urgent as from February on our 
 normal
 product development team would like to take over and focus on making
 Syncope work nicely in OSGi.
 I hope this does not mean that you will disappear once the CXF migration is
 done, it would be very bad for Syncope.

I can understand your worries. And no, we will not disappear once CXF migration 
is done. But of course we will spend less time in Syncope topics as currently. 
The last few weeks I was working more or less every day with syncope topics. 
This was fine, since Syncope topics matched with our current project goals. But 
talend understands that a committership requires continues activity within 
these projects. Thus I'll be able to continue working on Syncope topics (not 
aligned with project topics), once CXF migration is done. Of course not 5 days 
a week.

 And, for my curiosity: who is the normal product development team? Are
 you part of it? Are the people from this team already part of this project
 (Syncope)?

No. Our product team has not really started working with syncope. We just told 
them, that they should, because Syncope has already some nice features and an 
even greater potential. ;-)

  But the good news is, that I found a way how we could solve this
  dilemma ;-) The main problem (as mentioned earlier) with SVN is merging
 of renamed files. So my proposal would be to not rename any classes within
 a development branch. But instead leaving Controller classes as they are, and
 introducing new *ServiceImpl classes in addition to that. The current
 implementation of those *ServiceImpl classes would be to call matching
 methods of Controller classes (basically same idea for server side as we
 already applied on client side with SpringServiceProxy classes). Once we all
 agree with new ServiceInterfaces and switching from Spring webservices to
 CXF we can copy code from controller classes and place this code in
 *ServiceImpl classes and then delete controller classes.
  The advantage of this proposal is, that we can make all REST Services run in
 CXF and Spring at the same time, without any conflicts!

  If other syncope committers agree we could even make these changes in
 trunk and release this as an early preview in 1.1.0. But even if not, we can 
 get
 the migration done in a branch and then merge branch back to trunk after
 1.1.0 release.

 If, as it seems there is no other way out, I'd propose to move back the CXF
 migration to 1.1.0 (as actually OSGi is still there) so that no additional 
 branch is
 created. This is valid as long as Spring MVC interfaces are still working as 
 now,
 as you said above.

Yes, Spring MVC interfaces will not be affected

RE: [Discussion] New REST Service Interfaces - Entitlements

2013-01-17 Thread Jan Bernhardt

Hi Syncoper,

The following changes are proposed regarding  AuthenticationController:

=== Renaming Service ===
Rename AuthenticationController to EntitlementService(Impl), since containing 
methods have little to nothing to do with authentication. It is only about 
Entitlements...

=== Changing response Type ===
listEntitlements() returns a ListString whereas getEntitlements() returns a 
SetString.

From my point of view both methods should return a SET since entitlements have 
no order and cannot exists or be assigned more than once.

Due to some JAX-B / JAX-RS limitations, it is not possible to return a 
collection with primitive data types in java. A wrapper class is required, e.g. 
SetEntitlementTO.

EntitlementTO can be modeled in one of two ways: 

Option 1:
EntitlementTOs
   EntitlementTOROLE_ADMIN/EntitlementTO
   EntitlementTOROLE_SUPERUSER/EntitlementTO
/EntitlementTOs

Option 2:
EntitlementTOs
   EntitlementTO
  nameROLE_ADMIN/name
  /EntitlementTO
   EntitlementTO
  name ROLE_SUPERUSER /name
  /EntitlementTO
/EntitlementTOs

Option 1 matches more or less current marshaling. I personally would prefer 
Option 2 because this would give us the opportunity to easily extend 
EntitlementTO at a later point (if needed) without becoming incompatible with 
previous version.

WDYT?

All of these changes will not apply to current Spring Controller/Services, but 
only future CXF REST Service. So AuthenticationController will not be renamed 
now, and responsetype of AuthenticationController will not change. Changes only 
apply for new Service Interface and (Proxy) Implementation.

Best regards.
Jan

RE: [Discussion] New REST Service Interfaces - Entitlements

2013-01-17 Thread Jan Bernhardt

And what I forgott to mention: listEntitlements and getEntitlements are not 
very self-explanatory. A better name would be getAllEntitlements and 
getMyEntitlements.

Regards.
Jan

 -Original Message-
 From: Jan Bernhardt [mailto:jbernha...@talend.com]
 Sent: Donnerstag, 17. Januar 2013 14:04
 To: dev@syncope.apache.org
 Subject: RE: [Discussion] New REST Service Interfaces - Entitlements
 
 Hi Syncoper,
 
 The following changes are proposed regarding  AuthenticationController:
 
 === Renaming Service ===
 Rename AuthenticationController to EntitlementService(Impl), since
 containing methods have little to nothing to do with authentication. It is 
 only
 about Entitlements...
 
 === Changing response Type ===
 listEntitlements() returns a ListString whereas getEntitlements() returns a
 SetString.
 
 From my point of view both methods should return a SET since entitlements
 have no order and cannot exists or be assigned more than once.
 
 Due to some JAX-B / JAX-RS limitations, it is not possible to return a 
 collection
 with primitive data types in java. A wrapper class is required, e.g.
 SetEntitlementTO.
 
 EntitlementTO can be modeled in one of two ways:
 
 Option 1:
 EntitlementTOs
EntitlementTOROLE_ADMIN/EntitlementTO
EntitlementTOROLE_SUPERUSER/EntitlementTO
 /EntitlementTOs
 
 Option 2:
 EntitlementTOs
EntitlementTO
   nameROLE_ADMIN/name
   /EntitlementTO
EntitlementTO
   name ROLE_SUPERUSER /name
   /EntitlementTO
 /EntitlementTOs
 
 Option 1 matches more or less current marshaling. I personally would prefer
 Option 2 because this would give us the opportunity to easily extend
 EntitlementTO at a later point (if needed) without becoming incompatible
 with previous version.
 
 WDYT?
 
 All of these changes will not apply to current Spring Controller/Services, but
 only future CXF REST Service. So AuthenticationController will not be
 renamed now, and responsetype of AuthenticationController will not
 change. Changes only apply for new Service Interface and (Proxy)
 Implementation.
 
 Best regards.
 Jan

[Discussion] CXF migration (branches)

2013-01-16 Thread Jan Bernhardt

Hi Syncopers,

all preparation tasks are more or less done for CXF migration, so next we would 
like to start with actual CXF migration.

Since we are planning to release Syncope 1.1.0 soon I can see two reasonable 
solutions to continue.


1.   Creating a release branch for 1.1.0 and making sure this branch is 
stable and give it some time for additional test before official stable 
release will take place. CXF migration would start directly in trunk.

2.   Creating a CXF branch and continue working on trunk for 1.1.0 release.

I would prefer option 1 best. I think having a release branch prior to office 
release is a good practice in general.
I expect quite some refactoring during CXF migration (which is not mandatory in 
all cases but expedient), for example renaming some packages (removing client 
from Types, TOs, ... since they are rather common classes used on server and 
client site than specific only to the client) and I would also like to rename 
*Controller classes to *ServiceImpl since these classes do not act as 
controller for a workflow or GUI but rather offer some REST services. SVN has 
some limitations to handle renamed files when it comes to merging updates. Thus 
it could be quite painful to keep a cxf branch in sync with trunk.

WDYT? Could we start a release branch?

Best regards.
Jan

Cosole REST Service Client implements Serializable ?

2013-01-14 Thread Jan Bernhardt

Hi Syncopers,

I'm currently updating syncope console to use new REST Service Interface (with 
old Spring proxy variant). And since my Eclipse is complaining about a missing 
serialVersionUID I was wondering why does BaseRestClient implements 
Serializable?

Is there any need to make the rest client persistent to store in a DB or send 
it over the wire? I would like to remove implements Serializable since it looks 
wrong to me, but before I do this, I would like to double check with you, if 
there is a special reason for this and thus a need to keep this interface.

Best regards.
Jan

RE: Console is not working with trunk version

2013-01-11 Thread Jan Bernhardt

Hi Francesco,

I investigated a little more into this issue and discovered that my issue is 
related to [SYNCOPE-244].

For some reason my PropertyPlaceholderConfigurer does not work as expected. 
Just take a look in the attached log file.

The real strange thing is, that syncope-console tries to put my system %PATH% 
between host:port and url suffix (see attached log), instead of the path 
specified in configuration.property!

Maybe a solution is to rename the property key path to rootPath ?

I also discovered problems after setting syncope.console.configuration as a 
system property. I use Windows and therefore I tried both variants with 
backslash (\) and slash (/) in my filepath. But in both cases I only get the 
following warning in my log file:

09:36:49.341 INFO  
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer - 
Loading properties file from URL [file:]
09:36:49.341 WARN  
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer - Could 
not load properties from URL [file:]:  (The system cannot find the path 
specified)

Was someone else also tried this new feature under windows?

Best regards.
Jan


 -Original Message-
 From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
 Sent: Donnerstag, 10. Januar 2013 18:09
 To: dev@syncope.apache.org
 Subject: Re: Console is not working with trunk version
 
 On 10/01/2013 17:44, Jan Bernhardt wrote:
  Hi Francesco,
 
  Thanks for investigating!
 
  After creating  a new Syncope project and not making any changes, I was
 also able to run syncope in embedded mode.
 
  But I still get the same exception, when I try to make it run in a real
 environment. I guess I will have to investigate it a little more...
 
  I'll let you know as soon as I find the reason/solution.
 
 I have just copied core/target/syncope.war and console/target/syncope-
 console.war under $CATALINA_HOME/webapps, started my local
 PostgreSQL server and finally started Tomcat.
 
 Everything is working as well.
 
 Moreover, I have also defined a datasource (in
 $CATALINA_HOME/conf/context.xml) as follows:
 
  Resource name=jdbc/syncopeDataSource auth=Container
 type=javax.sql.DataSource
 factory=org.apache.tomcat.jdbc.pool.DataSourceFactory
 testWhileIdle=true
testOnBorrow=true testOnReturn=true
 validationQuery=SELECT 1 validationInterval=3
maxActive=50 minIdle=2 maxWait=1 initialSize=2
 removeAbandonedTimeout=2
removeAbandoned=true logAbandoned=true
 suspectTimeout=2
timeBetweenEvictionRunsMillis=5000
 minEvictableIdleTimeMillis=5000
 jdbcInterceptors=org.apache.tomcat.jdbc.pool.interceptor.ConnectionStat
 e;org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer
username=syncope password=syncope
 driverClassName=org.postgresql.Driver
url=jdbc:postgresql://localhost:5432/syncope/
 
 then uncommented the resource-ref/ at the end of
 $CATALINA_HOME/webapps/syncope/WEB-INF/web.xml and restarted
 Tomcat. All this to make Syncope work with real datasource rather than
 Spring's emulated datasource.
 
 Everything is working as well.
 
 You should try to look at all logs (including Tomcat's) during startup...
 
 Regards.
 
  [1]
 
 https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+re
 a
  l+environments#RunSyncopeinrealenvironments-ApacheTomcat7
 
  -Original Message-
  From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
  Sent: Donnerstag, 10. Januar 2013 17:13
  To: dev@syncope.apache.org
  Subject: Re: Console is not working with trunk version
 
  Jan,
  everything is working for me, at least in embedded mode (I haven't
  tried yet to deploy to an external container).
 
  Here is what I did, following instructions at [1]
 
  mvn archetype:generate \
-DarchetypeGroupId=org.apache.syncope \
-DarchetypeArtifactId=syncope-archetype \ -
  DarchetypeRepository=http://repository.apache.org/content/repositorie
  s/s
  napshots
  \
-DarchetypeVersion=1.1.0-SNAPSHOT
 
  then, from the generated directory
 
  mvn clean package
  cd console
  mvn -Pembedded
 
  At this point I am able to log in to
  http://localhost:9080/syncope-console/ and operate normally.
 
  Could you check this, please?
 
  Regards.
 
  [1]
 
 https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Sync
  ope+project
 
  On 10/01/2013 16:51, Jan Bernhardt wrote:
  Thanks!
 
  BTW I also tried the embedded mode, also with the same exception...
 
  Regards.
  Jan
 
 
  -Original Message-
  From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
  Sent: Donnerstag, 10. Januar 2013 15:50
  To: dev@syncope.apache.org
  Subject: Re: Console is not working with trunk version
 
  On 10/01/2013 15:37, Jan Bernhardt wrote:
  Hi Francesco,
 
  I used our archetype to generate a new project and then deployed
  this one
  to Tomcat 7.
  First I used my (old) syncope postgres DB settings. But I also
  created a new
  (empty) DB

[jira] [Comment Edited] (SYNCOPE-244) Make external property file usage possible


[ 
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551002#comment-13551002
 ] 

Jan Bernhardt edited comment on SYNCOPE-244 at 1/11/13 9:29 AM:


Property path in file configuration.properties causes problems with system 
property which has the same name (on Windows systems). Renaming path to 
rootPath or coreRootPath ... solved this issue.
(Attention: Renaming also needs to be applied in applicationContext.xml)

  was (Author: jan4talend):
Property path in file configuration.properties causes problems with 
system property which has the same name. Renaming path to rootPath or 
coreRootPath ... solved this issue.
(Attention: Renaming also needs to be applied in applicationContext.xml)
  
 Make external property file usage possible
 --

 Key: SYNCOPE-244
 URL: https://issues.apache.org/jira/browse/SYNCOPE-244
 Project: Syncope
  Issue Type: Improvement
  Components: console
Affects Versions: 1.1.0
Reporter: Ernst Vorsteveld
Assignee: Francesco Chicchiriccò
Priority: Minor
 Fix For: 1.1.0


 Syncope console has a property file named configuration.properties, that 
 contains property values which are environment specific.
 Everytime Syncope is installed on some servlet container, I need to do a 
 change property values in configuration.properties for the environment I am 
 working on and do a build.
 I think that it is possible to move the configuration.properties out of the 
 build, and configure the properties in a file per environment.
 We could do this by changing the 
 console/src/main/resources/applicationContext.xml.
 Now the context file has for the configuration.properties file:
  bean id=propertyConfigurer
 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=locations
   list
 valueclasspath:configuration.properties/value
   /list
 /property
   /bean
 If we change this and add another bean:
 bean id=propertyConfigurer2 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=order value=1/
 property name=location 
 value=file:#{(systemProperties['user.home'] + 
 '/.configuration.properties')}/
 property name=ignoreResourceNotFound value=true/
 property name=ignoreUnresolvablePlaceholders value=true/
 /bean
 We only have to create a .configuration.properties file in the home directory 
 of the user that runs the servlet container on which syncope is deployed. If 
 the file is not found, it still the default configuration.properties file 
 from within the war file is used.

--
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] [Assigned] (SYNCOPE-244) Make external property file usage possible


 [ 
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Bernhardt reassigned SYNCOPE-244:
-

Assignee: Jan Bernhardt  (was: Francesco Chicchiriccò)

 Make external property file usage possible
 --

 Key: SYNCOPE-244
 URL: https://issues.apache.org/jira/browse/SYNCOPE-244
 Project: Syncope
  Issue Type: Improvement
  Components: console
Affects Versions: 1.1.0
Reporter: Ernst Vorsteveld
Assignee: Jan Bernhardt
Priority: Minor
 Fix For: 1.1.0


 Syncope console has a property file named configuration.properties, that 
 contains property values which are environment specific.
 Everytime Syncope is installed on some servlet container, I need to do a 
 change property values in configuration.properties for the environment I am 
 working on and do a build.
 I think that it is possible to move the configuration.properties out of the 
 build, and configure the properties in a file per environment.
 We could do this by changing the 
 console/src/main/resources/applicationContext.xml.
 Now the context file has for the configuration.properties file:
  bean id=propertyConfigurer
 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=locations
   list
 valueclasspath:configuration.properties/value
   /list
 /property
   /bean
 If we change this and add another bean:
 bean id=propertyConfigurer2 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=order value=1/
 property name=location 
 value=file:#{(systemProperties['user.home'] + 
 '/.configuration.properties')}/
 property name=ignoreResourceNotFound value=true/
 property name=ignoreUnresolvablePlaceholders value=true/
 /bean
 We only have to create a .configuration.properties file in the home directory 
 of the user that runs the servlet container on which syncope is deployed. If 
 the file is not found, it still the default configuration.properties file 
 from within the war file is used.

--
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-244) Make external property file usage possible


[ 
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551022#comment-13551022
 ] 

Jan Bernhardt commented on SYNCOPE-244:
---

YES, I can do that.

Regards.
Jan




 Make external property file usage possible
 --

 Key: SYNCOPE-244
 URL: https://issues.apache.org/jira/browse/SYNCOPE-244
 Project: Syncope
  Issue Type: Improvement
  Components: console
Affects Versions: 1.1.0
Reporter: Ernst Vorsteveld
Assignee: Jan Bernhardt
Priority: Minor
 Fix For: 1.1.0


 Syncope console has a property file named configuration.properties, that 
 contains property values which are environment specific.
 Everytime Syncope is installed on some servlet container, I need to do a 
 change property values in configuration.properties for the environment I am 
 working on and do a build.
 I think that it is possible to move the configuration.properties out of the 
 build, and configure the properties in a file per environment.
 We could do this by changing the 
 console/src/main/resources/applicationContext.xml.
 Now the context file has for the configuration.properties file:
  bean id=propertyConfigurer
 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=locations
   list
 valueclasspath:configuration.properties/value
   /list
 /property
   /bean
 If we change this and add another bean:
 bean id=propertyConfigurer2 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=order value=1/
 property name=location 
 value=file:#{(systemProperties['user.home'] + 
 '/.configuration.properties')}/
 property name=ignoreResourceNotFound value=true/
 property name=ignoreUnresolvablePlaceholders value=true/
 /bean
 We only have to create a .configuration.properties file in the home directory 
 of the user that runs the servlet container on which syncope is deployed. If 
 the file is not found, it still the default configuration.properties file 
 from within the war file is used.

--
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-244) Make external property file usage possible


[ 
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551026#comment-13551026
 ] 

Jan Bernhardt commented on SYNCOPE-244:
---

path issue is fixed.

But I will keep this issue open, because I was not able to actually use the 
system property to locate my property file (under windows), as this was the 
goal of this issue! But at least renaming the path property allows one to use 
syncope properties via classpath (the old way).

Does someone else has an idea of what could be the issue here?

 Make external property file usage possible
 --

 Key: SYNCOPE-244
 URL: https://issues.apache.org/jira/browse/SYNCOPE-244
 Project: Syncope
  Issue Type: Improvement
  Components: console
Affects Versions: 1.1.0
Reporter: Ernst Vorsteveld
Assignee: Jan Bernhardt
Priority: Minor
 Fix For: 1.1.0


 Syncope console has a property file named configuration.properties, that 
 contains property values which are environment specific.
 Everytime Syncope is installed on some servlet container, I need to do a 
 change property values in configuration.properties for the environment I am 
 working on and do a build.
 I think that it is possible to move the configuration.properties out of the 
 build, and configure the properties in a file per environment.
 We could do this by changing the 
 console/src/main/resources/applicationContext.xml.
 Now the context file has for the configuration.properties file:
  bean id=propertyConfigurer
 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=locations
   list
 valueclasspath:configuration.properties/value
   /list
 /property
   /bean
 If we change this and add another bean:
 bean id=propertyConfigurer2 
 class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
 property name=order value=1/
 property name=location 
 value=file:#{(systemProperties['user.home'] + 
 '/.configuration.properties')}/
 property name=ignoreResourceNotFound value=true/
 property name=ignoreUnresolvablePlaceholders value=true/
 /bean
 We only have to create a .configuration.properties file in the home directory 
 of the user that runs the servlet container on which syncope is deployed. If 
 the file is not found, it still the default configuration.properties file 
 from within the war file is used.

--
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-259) Create transitional Service interfaces and switch tests and console to use them