[
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved SYNCOPE-244.
Resolution: Fixed
About working in Windows, it took me a while to setup ev
[
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned SYNCOPE-244:
--
Assignee: Francesco Chicchiriccò
> Make external property file usa
[
https://issues.apache.org/jira/browse/SYNCOPE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557336#comment-13557336
]
Hudson commented on SYNCOPE-280:
Integrated in Syncope-trunk #455 (See
[https://builds.a
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin resolved SYNCOPE-268.
-
Resolution: Fixed
> Enable Rest IntegrationTests to run more than once (per build)
>
[
https://issues.apache.org/jira/browse/SYNCOPE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557319#comment-13557319
]
Andrei Shakirin commented on SYNCOPE-280:
-
InvalidPolicyType will be also inherit
[
https://issues.apache.org/jira/browse/SYNCOPE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557308#comment-13557308
]
Hudson commented on SYNCOPE-277:
Integrated in Syncope-trunk #454 (See
[https://builds.a
[
https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557307#comment-13557307
]
Hudson commented on SYNCOPE-231:
Integrated in Syncope-trunk #454 (See
[https://builds.a
Andrei Shakirin created SYNCOPE-280:
---
Summary: Update some checked exceptions to runtime ones
Key: SYNCOPE-280
URL: https://issues.apache.org/jira/browse/SYNCOPE-280
Project: Syncope
Issue
[
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557261#comment-13557261
]
Francesco Chicchiriccò commented on SYNCOPE-252:
About javax.ws.rs-api, a
[
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557253#comment-13557253
]
Jan Bernhardt commented on SYNCOPE-252:
---
Yes, you are right, javax.ws.rs:javax.ws.r
> I don't understand why WorkflowException should be mapped to
> INTERNAL_SERVER_ERROR: you get workflow exceptions when something is
> not allowed within the current workflow instance, for example. There is no
> error on the server, the error is on the client asking for a workflow action
> not
>
[
https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557241#comment-13557241
]
Hudson commented on SYNCOPE-231:
Integrated in Syncope-trunk #452 (See
[https://builds.a
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557240#comment-13557240
]
Hudson commented on SYNCOPE-268:
Integrated in Syncope-trunk #452 (See
[https://builds.a
On 18/01/2013 15:04, Andrei Shakirin wrote:
Hi,
From proposals regarding remote exceptions in [1], I am going to do the
following during CXF migration:
1) Update HTTP mapping codes (see "Mapping exceptions to HTTP codes")
I don't understand why WorkflowException should be mapped to
INTERNAL
[
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557224#comment-13557224
]
Francesco Chicchiriccò commented on SYNCOPE-252:
If you are only explicit
Hi,
>From proposals regarding remote exceptions in [1], I am going to do the
>following during CXF migration:
1) Update HTTP mapping codes (see "Mapping exceptions to HTTP codes")
2) Update some checked exceptions to runtime ones (see "Checked vs Runtime
exceptions")
WDYT?
Cheers,
Andrei.
> -
[
https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557214#comment-13557214
]
Jan Bernhardt commented on SYNCOPE-252:
---
I decided to use Jackson instead of Jettis
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557213#comment-13557213
]
Andrei Shakirin commented on SYNCOPE-268:
-
Actually all tests are re-runnable exc
[
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
>
> Please don't forget that there is people out there using Syncope core
> *without* (or not exclusively via) the admin console.
> Currently, they only needs the syncope-client dependency (+Spring if they
> want to rely upon RestTemplate) in their java apps.
>
> Moreover, some client classes (th
> -Original Message-
> From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
> Sent: Freitag, 18. Januar 2013 10:25
> To: dev@syncope.apache.org
> Subject: Re: [Discussion] New REST Service Interfaces - Entitlements
>
>
> Il giorno 18/gen/2013, alle ore 09.47, Jan Bernhardt ha scritto:
>
fabio martelli created SYNCOPE-279:
--
Summary: Connector instance timeout
Key: SYNCOPE-279
URL: https://issues.apache.org/jira/browse/SYNCOPE-279
Project: Syncope
Issue Type: Improvement
Il giorno 18/gen/2013, alle ore 09.47, Jan Bernhardt ha scritto:
>>>
>>> May be a rule or a validity date or something like this.
>>> I'll keep the possibility to extend EntitlementTO.
>>
>> A validity date would not be necessary. It is only important to tell the
>> unmarshaller to be LAX with
Il giorno 18/gen/2013, alle ore 09.21, Jan Bernhardt ha scritto:
> Hi Fabio,
>
>>>
>>> === Renaming Service ===
>>> Rename AuthenticationController to EntitlementService(Impl), since
>> containing methods have little to nothing to do with authentication. It is
>> only
>> about Entitlements...
On 18/01/2013 09:43, Jan Bernhardt wrote:
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
> 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).
Than is absolutely OK for me. + 1.
Andrei.
>
> Best regards.
> Jan
I would rather do it in the annotations. Internally we often have a
internal class without TO and a transfer object that ends in TO.
So I think it makes sense to differentiate them on the class level.
Christian
On 18.01.2013 09:51, Jan Bernhardt wrote:
>> Btw. I would rather name the xml element
>
> 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
> >
> > May be a rule or a validity date or something like this.
> > I'll keep the possibility to extend EntitlementTO.
>
> A validity date would not be necessary. It is only important to tell the
> unmarshaller to be LAX with the received document. By this the
> ummarshaller will only unmarshall
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,
> > [.
> >>>
> >>> 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.
> >> Agree with you for the reason given
Hi Christian,
> >> === Renaming Service ===
> >> Rename AuthenticationController to EntitlementService(Impl), since
> containing methods have little to nothing to do with authentication. It is
> only
> about Entitlements...
> > Why not AuthorizationController or AccessController? I'd prefer the
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,
Hi Fabio,
> >
> > === Renaming Service ===
> > Rename AuthenticationController to EntitlementService(Impl), since
> containing methods have little to nothing to do with authentication. It is
> only
> about Entitlements...
>
> Why not AuthorizationController or AccessController? I'd prefer the fi
34 matches
Mail list logo
