Creating events for changes and spi for transport of events
I was listening to Colm´s presentation about customizing syncope with camel
rotues. It sounds like a very powerful combination as you can influence all
changes.
For some simple cases like just listening to changes in syncope the camel
routes look a bit complicated though.
So I wonder if it would make sense to create some central event hub inside
syncope that gets notified of all changes and allows to easily attach
messaging systems.
I could imagine something like this:
interface EventBroker {
sendEvent(String topic, Object event)
}
There could be different event classes for each type of change. If those
events have JAXB annotations it is very easy to create xml or json from
them.
The syncope classes where the events happen would just inject the
EventBroker interface and send their events.
The EventBroker would then forward the events to all EventListeners
present. An EventListener would look like that:
interface EventListener {
onEvent(String topic, Object event)
}
So we could provide some implementations of EventListener like for ActiveMQ
and Kafka. Additionally users could also implement the interface and attach
additional messaging systems.
What do you think? Does something like this already exist? Would it make
sense to add this mechanism to syncope?
If there is interest I am willing to create the Broker as well as ActiveMQ
and Kafka impls. I am not familiar enough with the individual source for
the events to do the integration but I think it should be very easy for any
syncope core developer to add them.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
[jira] [Assigned] (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 ] Christian Schneider reassigned SYNCOPE-246: --- Assignee: (was: Christian Schneider) > 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 > 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
Re: [DISCUSS] Replace logback with log4j 2
+1 For switching to log4j. I would also keep the slf4j layer. This minimizes direct dependencies on the log framework and also works great in OSGi. Christian 2013/7/22 Francesco Chicchiriccò > Hi all, > I have recently read a stunning post from Christian Grobmeier [1] and I > was thinking why not to switch the trunk (1.2.0) from logback to log4j 2 > (with new AsyncLoggers, of course!). > I was also thinking to keep the SLF4J layer, so that code changes would be > minimal. > > Besides performance benefit, we will also increase our non-ASF dependency > level. > > WDYT? > > [1] http://www.grobmeier.de/log4j-**2-performance-close-to-insane-** > 20072013.html#.Ue0KLRe9hyc<http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.Ue0KLRe9hyc> > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/> > > -- -- Christian Schneider http://www.liquid-reality.de<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [VOTE] Apache Syncope 1.1.0
+1 (non binding) Christian On 05.04.2013 13:29, Francesco Chicchiriccò wrote: I've created a 1.1.0 release, with the following artifacts up for a vote: SVN source tag (r1464912): http://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.0/ List of changes: http://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.0/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-066/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-066/org/apache/syncope/syncope/1.1.0/syncope-1.1.0-source-release.zip Staging site: http://syncope.apache.org/1.1.0/ PGP release keys (signed using 273DF287): http://www.apache.org/dist/syncope/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: JAAS LoginModule for Syncope
There could be some overlap but I am not sure how much. The issues in the roadmap sound mostly like authentication to access syncope. What I have in mind is authentication for other apps with syncope as a auth backend. Of course you might want to investigate using JAAS for authentication to syncope to make it flexible. Christian On 07.03.2013 17:22, Francesco Chicchiriccò wrote: On 07/03/2013 17:18, Christian Schneider wrote: Hi, I am currently working on a JAAS based authentication for the CXF Secure Token Service. Colm had already built custom login code for STS. So after the switch to JAAS I wonder if there would be interest in a general JAAS login module that talks to Syncope as backend? We could implement this in the syncope project. I would try to implement this module with minimal dependencies in mind. Ideally just with jdk classes so it is as easy as possible to install the module. Hi Christian, this looks very interesting and fits together with some work we have on roadmap on the authentication / authorization side [1]. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap#Roadmap-3.0.0%28Maggiore%29 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
JAAS LoginModule for Syncope
Hi, I am currently working on a JAAS based authentication for the CXF Secure Token Service. Colm had already built custom login code for STS. So after the switch to JAAS I wonder if there would be interest in a general JAAS login module that talks to Syncope as backend? We could implement this in the syncope project. I would try to implement this module with minimal dependencies in mind. Ideally just with jdk classes so it is as easy as possible to install the module. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Resolved] (SYNCOPE-312) Introducing UserWorkflowService
[ https://issues.apache.org/jira/browse/SYNCOPE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SYNCOPE-312. - Resolution: Fixed Documentation should now reflect the UserWorkflowService > 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
Re: BasicAuth realm String
+1 Sounds good On 27.02.2013 08:49, Francesco Chicchiriccò wrote: On 26/02/2013 23:03, Colm O hEigeartaigh wrote: Hi all, The core's RestServiceExceptionMapper defines the following: private static final String BASIC_REALM_UNAUTHORIZED = "Basic realm=\"Spring Security Application\""; I propose to change this to a more neutral realm, as this appears when authenticating to access the new CXF-based REST API as well. +1 Any objections or suggestions? What about "Apache Syncope authentication"? Regards. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Resolved] (SYNCOPE-312) Introducing UserWorkflowService
[ https://issues.apache.org/jira/browse/SYNCOPE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SYNCOPE-312. - Resolution: Fixed > 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] [Assigned] (SYNCOPE-312) Introducing UserWorkflowService
[ https://issues.apache.org/jira/browse/SYNCOPE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned SYNCOPE-312: --- Assignee: Christian Schneider > 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SYNCOPE-287. - Resolution: Fixed > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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] Adding a version number to the Wiki pages for releases
I think labels would not help a lot. Labels allow to mark several pages to belong to the same theme. But we need just one page per version. This is how camel does it: http://camel.apache.org/download.html http://camel.apache.org/camel-2103-release.html http://camel.apache.org/camel-295-release.html Basically I like the idea of one page per Version. In syncope we currently have one page per Minor version and list all bugfix versions inside the same page which is also ok. So the only thing I am missing is the version number in the page title and the url. This allows at camel to look at a url and instantly know that it is about. Chrisitian On 13.02.2013 11:31, Francesco Chicchiriccò wrote: > On 13/02/2013 10:41, Christian Schneider wrote: >> I think the release pages are not really versioned content like code. >> All pages are visible in parallel. > > Of course... > >> The name only makes it easier for users to see what each release is. > > Look at what Atlassian does for Confluence own documentation: > > https://confluence.atlassian.com/display/CONF35/Confluence+Documentation+Home > > > https://confluence.atlassian.com/display/CONF40/Confluence+Documentation+Home > > > > This is definitely too much: what if we empower page labels for this? > Take as example the label "practice" > > https://cwiki.apache.org/confluence/label/SYNCOPE/practice > > and imagine if we define label for each version. > > WDYT? > >> On 13.02.2013 10:04, Francesco Chicchiriccò wrote: >>> On 13/02/2013 09:49, Christian Schneider wrote: >>>> Hi all, >>>> >>>> our current wiki pages for the minor releases only have names. While >>>> experienced syncope users may already know which version number this >>>> correlates to new users will have no clue. >>>> >>>> So I propose to add the version number to the names of the wiki pages >>>> like this: >>>> >>>> 0.5 - Crescendo >>>> 0.6 - Sostenuto >>>> 0.7 - Ritornello >>>> 1.0 - Espressivo >>>> 1.1 - Ad libitum >>>> >>>> What do you think? >>> I am not sure whether this is the best practice for handling versioned >>> content on wiki pages: how the other ASF projects deal with this? >>> >>> Regards. > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [Discuss] Adding a version number to the Wiki pages for releases
I think the release pages are not really versioned content like code. All pages are visible in parallel. The name only makes it easier for users to see what each release is. Christian On 13.02.2013 10:04, Francesco Chicchiriccò wrote: > On 13/02/2013 09:49, Christian Schneider wrote: >> Hi all, >> >> our current wiki pages for the minor releases only have names. While >> experienced syncope users may already know which version number this >> correlates to new users will have no clue. >> >> So I propose to add the version number to the names of the wiki pages >> like this: >> >> 0.5 - Crescendo >> 0.6 - Sostenuto >> 0.7 - Ritornello >> 1.0 - Espressivo >> 1.1 - Ad libitum >> >> What do you think? > > I am not sure whether this is the best practice for handling versioned > content on wiki pages: how the other ASF projects deal with this? > > Regards. > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[Discuss] Adding a version number to the Wiki pages for releases
Hi all, our current wiki pages for the minor releases only have names. While experienced syncope users may already know which version number this correlates to new users will have no clue. So I propose to add the version number to the names of the wiki pages like this: 0.5 - Crescendo 0.6 - Sostenuto 0.7 - Ritornello 1.0 - Espressivo 1.1 - Ad libitum What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Commented] (SYNCOPE-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576622#comment-13576622 ] Christian Schneider commented on SYNCOPE-287: - It works now.. many thanks. > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576618#comment-13576618 ] Christian Schneider commented on SYNCOPE-287: - My actual account should be "christian schneider". > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò >Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576610#comment-13576610 ] Christian Schneider commented on SYNCOPE-287: - Now I can read the page. But I can not edit any of the wiki pages. I will write the notes in a comment here so you can copy it to the wiki. > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576605#comment-13576605 ] Christian Schneider commented on SYNCOPE-287: - I can not access the new page. > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576567#comment-13576567 ] Christian Schneider commented on SYNCOPE-287: - I will add the rest migration details to the release notes. Where should I add these? Currently I did not find any release notes for 1.1.0? I assume there will be a new wiki page and an addition to the CHANGES file in svn. Is that correct? Should I create these? > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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-287) Information for release notes
[ https://issues.apache.org/jira/browse/SYNCOPE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned SYNCOPE-287: --- Assignee: Christian Schneider > Information for release notes > - > > Key: SYNCOPE-287 > URL: https://issues.apache.org/jira/browse/SYNCOPE-287 > Project: Syncope > Issue Type: Sub-task > Components: documentation >Reporter: Francesco Chicchiriccò > Assignee: Christian Schneider > Fix For: 1.1.0 > > > Release notes for 1.1.0 need to contain some description about the current > migration from Spring MVC to Apache CXF: > * Spring MVC-based REST interface is still available but will be removed in > future releases > * There is a migration guide available at... > * Integration tests are still performed against Spring MVC -- 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
+1
Christian
On 08.02.2013 09:12, Francesco Chicchiriccò wrote:
> On 08/02/2013 09:05, Jan Bernhardt wrote:
>> 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")
>> List 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);
>
> Hi Jan,
> I think I've finally got your point - it took me some time, though..
>
> getFormForUser() is not the only workflow-related method explicitly
> referencing users (userId in that case); there is also
> executeWorkflow() with UserTO for example, but if you take a look at
> method implementation there is even more.
>
> Hence my proposal: let's call it UserWorkflowService and let's move
> all the methods above (including getFormForUser()) to this new service.
>
> WDYT?
>
> Regards.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: "dbDump" in ReportService and ConfigurationService
In fact I recently changed dbDump to all/export I think. The problem was
that dbDump did never work.
Instead of the dbDump path it called the {key} path. So it returned an
empty configuration element. The test was still green though. So I added
a size check to the test.
As this ambiguity between {key} and a fixed path can happen any time I
wonder if we should change the paths for the lists like in this case the
configuration items to something like:
/configurations/items/{key} instead of /configurations/{key}.
Christian
On 07.02.2013 10:35, Francesco Chicchiriccò wrote:
> 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.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] User Service
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.
>
> 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?
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] User Service
One other idea for the username / userId based methods.
Why not simply use:
/users/{userIdorName}
So basically you could do
get /users/100 or get /users/chris@mydomain
We could handle both using
@GET
@Path("{userId}")
UserTO read(@PathParam("userId") String userId);
This is convenient for any kind of client and quite efficient at the
same time.
Christian
On 04.02.2013 14:00, Christian Schneider wrote:
> On 04.02.2013 12:41, Francesco Chicchiriccò wrote:
>> On 04/02/2013 12:12, Jan Bernhardt wrote:
>>>>
>>>> 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.
>> It is not matter of feeling, it is just incorrect: UserController and
>> RoleController make usage of workflow adapters to perform user and
>> role operations while the WorkflowController manipulates the workflow
>> definition, used to initialize and configure the workflow adapters.
> 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.
>
>>>>> 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?
>> Adding some bits to this: SYNCOPE-42 and SYNCOPE-91 introduced in
>> 1.0.0-incubating such methods that were absent before.
>>
>> Anyway, I am +-0 to remove such methods in 1.2.0.
> Perhaps these convenience methods show that it might be better to have
> the user name as a key in the rest service instead of the id.
> I am not really sure about this though. When talking with Jan about it
> he argued that a user name can change over time.
>
> On the other hand I think the user id we currently have is an internal
> thing of our database and may better be hidden to the outside.
>
> 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.
>
> I think it makes sense to think about these things to make the API as
> good as possible. On the other hand I think these considerations should
> not block the 1.1.0 release.
>
> Best regards
>
> Christian
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] User Service
On 04.02.2013 12:41, Francesco Chicchiriccò wrote:
> On 04/02/2013 12:12, Jan Bernhardt wrote:
>>>
>>>
>>> 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.
>
> It is not matter of feeling, it is just incorrect: UserController and
> RoleController make usage of workflow adapters to perform user and
> role operations while the WorkflowController manipulates the workflow
> definition, used to initialize and configure the workflow adapters.
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.
>
>>>> 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?
>
> Adding some bits to this: SYNCOPE-42 and SYNCOPE-91 introduced in
> 1.0.0-incubating such methods that were absent before.
>
> Anyway, I am +-0 to remove such methods in 1.2.0.
Perhaps these convenience methods show that it might be better to have
the user name as a key in the rest service instead of the id.
I am not really sure about this though. When talking with Jan about it
he argued that a user name can change over time.
On the other hand I think the user id we currently have is an internal
thing of our database and may better be hidden to the outside.
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.
I think it makes sense to think about these things to make the API as
good as possible. On the other hand I think these considerations should
not block the 1.1.0 release.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: IncompatiblePolicyException was made unchecked
Basically I prefer unchecked but this would rather be a general change to not use checked exceptions at all. I do not insist on this style though and will go with the majority. Christian Am 02.02.2013 11:26, schrieb Francesco Chicchiriccò: On 01/02/2013 17:44, Andrei Shakirin wrote: Can we agree on something here? My +1 for checked +1 from me as well. Regards. -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: IncompatiblePolicyException was made unchecked
Sorry about the long explanation that is completely unrelated to this special case but I think the discussion checked vs unchecked exceptions is a general thing so I write a general reasoning... In general checked Exceptions force the user of an API to handle an exception at exactly the point where it happens. Often thoughit is much easier to let an exception bubble up the stack to a general place where exceptions are handled. Checked exceptions also force to Map an exception at every layer of an application. The reason is that simply throwing exceptions over layer boundaries violates encapsulation. So my way of handling checked exceptions is: where they are forced upon me by an API I map them to an unchecked Exception as soon as possible to limit their effect / damage. I have found a nice explanation on this article http://www.javacodegeeks.com/2012/03/why-should-you-use-unchecked-exceptions.html In his famous book, *Clean code: a handbook of agile software craftsmanship*[3 <http://books.google.co.in/books/about/Clean_code.html?id=dwSfGQAACAAJ&redir_esc=y>], Robert C. Martin writes the below lines supporting Unchecked Exceptions. /The debate is over. For years Java programmers have debated over the benefits and liabilities //of checked exceptions. When checked exceptions were introduced in the first version //of Java, they seemed like a great idea. The signature of every method would list all of the //exceptions that it could pass to its caller. Moreover, these exceptions were part of the type/ /of the method. Your code literally wouldn't compile if the signature didn't match what your //code could do./ / / /At the time, we thought that checked exceptions were a great idea; and yes, they can //yield some benefit. However, it is clear now that they aren't necessary for the production of //robust software. C# doesn't have checked exceptions, and despite valiant attempts, C++ //doesn't either. Neither do Python or Ruby. Yet it is possible to write robust software in all //of these languages. Because that is the case, we have to decide---really---whether checked //exceptions are worth their price./ / / Here some more similar articles: http://tapestryjava.blogspot.in/2011/05/tragedy-of-checked-exceptions.html http://blogs.atlassian.com/2011/05/exceptions_are_bad/ http://misko.hevery.com/2009/09/16/checked-exceptions-i-love-you-but-you-have-to-go/ Christian Am 01.02.2013 14:36, schrieb Francesco Chicchiriccò: On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in-Rest-interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/java /org/apache/syncope/core/util/IncompatiblePolicyException.java?view=mar kup&pathrev=1401200 -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Discuss: Move InvalidSearchConditionException to common
No problem to make it checked. I just wanted to get feedback first before I introduce the exceptions in all the methods. Of course I hoped to persuade you to make it unchecked but as this is just my personal preference I do not insist on this :-) As having the exceptions in the client code is ok with you I will move the Exception and make it checked again. I will catch and log the exception in AttributableDataProvider. Christian Am 01.02.2013 12:06, schrieb Francesco Chicchiriccò: On 30/01/2013 13:25, Christian Schneider wrote: Hi Francesco, I am currently working on the patch to move the InvalidSearchConditionException and make it checked again. I am not sure if making it checked is a good idea. As the exception will now be part of the service interface I will have to add it to lots of methods. None of these methods really handles this exception. The reason for this is that before we used the RestTemplate to access the services. So it did not matter if the service throws a checked exception. We would not be forced to catch it. Now with the interfaces for the services we have to add the checked exception to the service interface if we want the impl to be able to throw it. So the client is also affected by that. Clear. In the end the exception now also appears in AttributableDataProvider which can not rethrow the exception as it would violate the IDataProvider interface. So I would have to catch it there but I have no idea what to do if it happens. As said before, this should never happen on the admin console since the wrapper is architected to generate only valid conditions and to check for correctness; anyway, the catch() block should only be able to log and report this error to the user. I created a gist of the patch so you can have a look: https://gist.github.com/4672932 So I see two possible solutions to improve this: 1) Make the exception unchecked again so it can be thrown by the services but has no effect on the client side 2) Catch the exception in the server impls and rethrow it as a RuntimeException so it does not affect the clients If the admin console is the only problem, we can easily find a fix there. If you still think having this checked is too much problematic for you, just leave it unchecked. Regards. -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Discuss: Move InvalidSearchConditionException to common
Hi Francesco, I am currently working on the patch to move the InvalidSearchConditionException and make it checked again. I am not sure if making it checked is a good idea. As the exception will now be part of the service interface I will have to add it to lots of methods. None of these methods really handles this exception. The reason for this is that before we used the RestTemplate to access the services. So it did not matter if the service throws a checked exception. We would not be forced to catch it. Now with the interfaces for the services we have to add the checked exception to the service interface if we want the impl to be able to throw it. So the client is also affected by that. In the end the exception now also appears in AttributableDataProvider which can not rethrow the exception as it would violate the IDataProvider interface. So I would have to catch it there but I have no idea what to do if it happens. I created a gist of the patch so you can have a look: https://gist.github.com/4672932 So I see two possible solutions to improve this: 1) Make the exception unchecked again so it can be thrown by the services but has no effect on the client side 2) Catch the exception in the server impls and rethrow it as a RuntimeException so it does not affect the clients What do you think? Christian On 30.01.2013 08:29, Francesco Chicchiriccò wrote: > On 28/01/2013 15:38, Francesco Chicchiriccò wrote: >> On 28/01/2013 15:36, Christian Schneider wrote: >>> Currently InvalidSearchConditionException is in core.persistence.dao >>> and >>> is a checked exception. >>> If we want to make this exception part of the UserService interface to >>> have it available on the client we will have to move it to common. >>> >>> Currently the console does not seem to use the exception on the client >>> side. So my preliminary solution to get it running is to make the >>> exception unchecked so I can pass it to the >>> exception mapper without having it in the interface. >>> >>> So basically the two things to discuss are if we want to move the >>> exception to common and if we want to make it unchecked. I personally >>> would do both. >> >> This exception is not used by the admin console because the code is >> done so that no invalid search conditions are sent to the core; >> however, other clients are likely to need this exception to be returned. >> >> Hence: +1 for moving it to common, but don't see enough reason to >> make it unchecked. > > I've noticed that this issue was moved to common as unchecked: any > additional reason behind not leaving it checked than the need to > change some interface method's signature? > > Regards. > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Move InvalidSearchConditionException to common
I changed the exception to unchecked only till we have a decision to make the service interface work. I will move the exception to common and make it checked again like discussed. Christian Am 30.01.2013 08:29, schrieb Francesco Chicchiriccò: On 28/01/2013 15:38, Francesco Chicchiriccò wrote: On 28/01/2013 15:36, Christian Schneider wrote: Currently InvalidSearchConditionException is in core.persistence.dao and is a checked exception. If we want to make this exception part of the UserService interface to have it available on the client we will have to move it to common. Currently the console does not seem to use the exception on the client side. So my preliminary solution to get it running is to make the exception unchecked so I can pass it to the exception mapper without having it in the interface. So basically the two things to discuss are if we want to move the exception to common and if we want to make it unchecked. I personally would do both. This exception is not used by the admin console because the code is done so that no invalid search conditions are sent to the core; however, other clients are likely to need this exception to be returned. Hence: +1 for moving it to common, but don't see enough reason to make it unchecked. I've noticed that this issue was moved to common as unchecked: any additional reason behind not leaving it checked than the need to change some interface method's signature? Regards. -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
[jira] [Resolved] (SYNCOPE-291) Move NotFoundException to core.persistence.dao
[ https://issues.apache.org/jira/browse/SYNCOPE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SYNCOPE-291. - Resolution: Fixed Oh sorry .. it is done > Move NotFoundException to core.persistence.dao > -- > > Key: SYNCOPE-291 > URL: https://issues.apache.org/jira/browse/SYNCOPE-291 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.1.0 > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.1.0 > > > The NotFoundException is currently located in util which is not such a > good place as it is part of the dao as well as service interfaces. > Like discussed on the dev list we agree to move this exception to > core.persistence.dao. > For the rest services the exception will be mapped to the > rs.NotFoundException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Issue with serializing ReportTO as it has an interface ReportletConf
I have an issue serializing and unserializing ReportTO using jaxb.
The problem is at the ReportletConf list:
public List getReportletConfs() {
return reportletConfs;
}
As ReportletConf is an interface JAXB can not handle it. So we get an
IllegalAnnotationException or similar and JAXB does not even initialize.
So I introduced the annotation below. This allowed the serialization to run.
@XmlElement(type=AbstractReportletConf.class)
The problem now is that the result of the serialization is not complete
and can not be deserialized into the actual classes.
This is how it looks (in an example I did with simplified classes:
testdesc
As you can see there is not enough information to detect the real class.
So I tried to change the signature to use the abstract class and not use
the annotation:
public List getReportletConfs()
This works:
http://www.w3.org/2001/XMLSchema-instance";
xsi:type="staticReportletConf">testdesc
>From the xsi:type jaxb knows the class to instantiate.
So there are the following questions:
- Is there a better way to achieve correct serialization of interfaces ?
- Would it be ok if I change ReportletTO to use the abstract class?
- I would like to avoid the xsi:type and instead have elements for each
class extending AbstractReportletConf. Is that possible?
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Discuss: Move InvalidSearchConditionException to common
Currently InvalidSearchConditionException is in core.persistence.dao and is a checked exception. If we want to make this exception part of the UserService interface to have it available on the client we will have to move it to common. Currently the console does not seem to use the exception on the client side. So my preliminary solution to get it running is to make the exception unchecked so I can pass it to the exception mapper without having it in the interface. So basically the two things to discuss are if we want to move the exception to common and if we want to make it unchecked. I personally would do both. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Moving core.util.NotFoundException
Ok. So I will move the NotFoundException to core.persistence.dao and make it a RuntimeException. I created issue https://issues.apache.org/jira/browse/SYNCOPE-291 to track this. Christian On 24.01.2013 12:33, Francesco Chicchiriccò wrote: > On 24/01/2013 12:25, Christian Schneider wrote: >> The NotFoundException is currently located in util which is not such a >> good place as it is part of the dao as well as service interfaces. >> >> So I propose to move this exception either to >> 1. common.services >> In this case the NotFoundException could also be used in the >> service >> interfaces. So we would not have to handle the http specific not found >> exception >> 2. core.persistence.dao >> In this case the NotFoundException would be private to the core and >> we would have to use e.g. the jax rs NotFoundException in the service >> interfaces > > I would opt for (2), guessing that "jax rs NotFoundException" has some > sort of more natural mapping to HTTP 404. > >> I also propose to change the exception to be unchecked to not force each >> caller to catch it. > > +1 > > Regards. > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Created] (SYNCOPE-291) Move NotFoundException to core.persistence.dao
Christian Schneider created SYNCOPE-291: --- Summary: Move NotFoundException to core.persistence.dao Key: SYNCOPE-291 URL: https://issues.apache.org/jira/browse/SYNCOPE-291 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.1.0 The NotFoundException is currently located in util which is not such a good place as it is part of the dao as well as service interfaces. Like discussed on the dev list we agree to move this exception to core.persistence.dao. For the rest services the exception will be mapped to the rs.NotFoundException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:30, Francesco Chicchiriccò wrote: > On 25/01/2013 17:28, Christian Schneider wrote: >> On 25.01.2013 17:18, Francesco Chicchiriccò wrote: >>> I also thought about this and if I should rather wait. My change only >>>> affects the new interface. So the old controller stays the same and >>>> stays active. The change should not affect anyone who uses the current >>>> spring based rest interface. >>>> As we already use the new interface in the console and the tests these >>>> are of course affected but this should be only internal. >>>> >>>> If you prefer I can roll back and wait for the result of the >>>> discussion. >>> For the moment it would be enough for me to have again a working admin >>> console, as it used to be before of this commit. >>> >>> Regards. >>> >> I will take care of this. I hoped to not affect the console. If I cant >> fix it easily I will roll back. > > I am about to commit a temporary workaround: take your time and fix it > properly, please. > I restored the old behaviour of isCreateAllowed which should fix the bug. The bug and the ugly code in Login show that using a header was probably not such a good idea after all. Sorry for breaking the console. I did not test the UI before the commit. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:18, Francesco Chicchiriccò wrote: > I also thought about this and if I should rather wait. My change only >> affects the new interface. So the old controller stays the same and >> stays active. The change should not affect anyone who uses the current >> spring based rest interface. >> As we already use the new interface in the console and the tests these >> are of course affected but this should be only internal. >> >> If you prefer I can roll back and wait for the result of the discussion. > > For the moment it would be enough for me to have again a working admin > console, as it used to be before of this commit. > > Regards. > I will take care of this. I hoped to not affect the console. If I cant fix it easily I will roll back. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:11, Sergey Beryozkin wrote: > Hi Christian > > On 25/01/13 15:56, Christian Schneider wrote: >> When doing the CXF version of the UserRequestService I found that our >> current UserRequestController does not really follow the rest ideas. >> >> The problem is that it does follow the idea of doing CRUD operations on >> resources. Some methods work with userId others with requestId. So for >> example the are create, update and delete operations but they >> do not mean the UserRequest but the underlying user. >> >> So I worked out a new interface that purely works on UserRequest and >> only supports POST, READ and DELETE. So basically if you want to create >> or delete or update a user you will POST a UserRequestTO in all cases. >> I added constructors to the UserRequestTO to make the use cases simpler. >> >> request to create a user: userRequestService.create(new >> UserRequestTO(userTO)); >> request to update a user: userRequestService.create(new >> UserRequestTO(userMod)); >> request to delete a user: userRequestService.create(new >> UserRequestTO(userTO.getId())); >> >> So what do you think about this? > > IMHO it would be nicer to avoid overloading proxy "create" request to > mean different things, definitely would not use "create" to mean > "delete" - perhaps it is a typo, the interface below suggests it might > be ? Would also use "update()" for updates > > Just my 2c :-) > Honestly I was confused by the old interface in the same way. Basically the idea is that the UserRequestService handles UserRequest resources. A UserRequest is a request to do something on a user it is not directly an operation on a user. So I used create in the meaning to create a new UserRequest like you would create a workflow instance. Of course the meaning of this request can be to delete a user at a later point but we are still creating a UserRequest at this point. So I think a POST of a new UserRequest is the right thing to do. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:07, Francesco Chicchiriccò wrote: > On 25/01/2013 16:56, Christian Schneider wrote: >> When doing the CXF version of the UserRequestService I found that our >> current UserRequestController does not really follow the rest ideas. >> >> The problem is that it does follow the idea of doing CRUD operations on >> resources. Some methods work with userId others with requestId. So for >> example the are create, update and delete operations but they >> do not mean the UserRequest but the underlying user. >> >> So I worked out a new interface that purely works on UserRequest and >> only supports POST, READ and DELETE. So basically if you want to create >> or delete or update a user you will POST a UserRequestTO in all cases. > > Problem: you've already made all these changes *without* discussing > this before, once again not taking into any account the domain > requirements nor the compatibility with existing components, but only > the technology aspects. > We must fix this ASAP. > I also thought about this and if I should rather wait. My change only affects the new interface. So the old controller stays the same and stays active. The change should not affect anyone who uses the current spring based rest interface. As we already use the new interface in the console and the tests these are of course affected but this should be only internal. If you prefer I can roll back and wait for the result of the discussion. Best regards Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Discuss: Rest interface for UserRequestService
When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.
The problem is that it does follow the idea of doing CRUD operations on
resources. Some methods work with userId others with requestId. So for
example the are create, update and delete operations but they
do not mean the UserRequest but the underlying user.
So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to create
or delete or update a user you will POST a UserRequestTO in all cases.
I added constructors to the UserRequestTO to make the use cases simpler.
request to create a user: userRequestService.create(new
UserRequestTO(userTO));
request to update a user: userRequestService.create(new
UserRequestTO(userMod));
request to delete a user: userRequestService.create(new
UserRequestTO(userTO.getId()));
So what do you think about this?
The only thing I really struggled with is the old isCreateAllowed
method. I implemented this using @Options and return the boolean in a
custom header. I am not sure if this is really the best way to do this
but it
follows the rest principles quite closely. The alternative would be to
do a get on a magic path like in the current spring service.
Best regards
Christian
--
Current Interface:
@RequestMapping(method = RequestMethod.POST, value = "/create")
public UserRequestTO create(@RequestBody final UserTO userTO);
@RequestMapping(method = RequestMethod.POST, value = "/update")
public UserRequestTO update(@RequestBody final UserMod userMod);
@RequestMapping(method = RequestMethod.GET, value = "/delete/{userId}")
public UserRequestTO delete(@PathVariable("userId") final Long userId)
@RequestMapping(method = RequestMethod.GET, value = "/list")
public List list();
@RequestMapping(method = RequestMethod.GET, value = "/read/{requestId}")
public UserRequestTO read(@PathVariable("requestId") final Long requestId);
@RequestMapping(method = RequestMethod.GET, value =
"/deleteRequest/{requestId}")
public UserRequestTO deleteRequest(@PathVariable("requestId") final Long
requestId);
New interface for CXF Service:
@Path("requests/user")
public interface UserRequestService {
public static final String SYNCOPE_CREATE_ALLOWED =
"Syncope-Create-Allowed";
@OPTIONS
Response getOptions();
@POST
Response create(UserRequestTO userRequestTO);
@GET
List list();
@GET
@Path("{requestId}")
UserRequestTO read(@PathParam("requestId") Long requestId);
@DELETE
@Path("{requestId}")
void delete(@PathParam("requestId") Long requestId);
}
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [VOTE] Apache Syncope 1.0.5
+1 (non binding) Christian Am 23.01.2013 19:24, schrieb Fabio Martelli: 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) -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Discuss: Moving core.util.NotFoundException
The NotFoundException is currently located in util which is not such a good place as it is part of the dao as well as service interfaces. So I propose to move this exception either to 1. common.services In this case the NotFoundException could also be used in the service interfaces. So we would not have to handle the http specific not found exception 2. core.persistence.dao In this case the NotFoundException would be private to the core and we would have to use e.g. the jax rs NotFoundException in the service interfaces I also propose to change the exception to be unchecked to not force each caller to catch it. Best regards Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Resolved] (SYNCOPE-288) Make setters of Transfer Objects (TO) compatible to CXF and JAXB
[
https://issues.apache.org/jira/browse/SYNCOPE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved SYNCOPE-288.
-
Resolution: Fixed
> Make setters of Transfer Objects (TO) compatible to CXF and JAXB
>
>
> Key: SYNCOPE-288
> URL: https://issues.apache.org/jira/browse/SYNCOPE-288
> Project: Syncope
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.1.0
> Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 1.1.0
>
>
> Like found in SYNCOPE-231 there is a way to make the setters of TOs work with
> CXF. So this issue is to change them to the new style.
> public void setOrders(List orders) {
> if (this.orders != orders) {
> this.orders.clear();
> this.orders.addAll(orders);
> }
> }
--
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
Open Wiki pages for CXF migration
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 Best regards Christian
[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-tabpanel&focusedCommentId=13560574#comment-13560574 ] Christian Schneider commented on SYNCOPE-246: - I just created a new issue for 1.1.0 and linked it. > 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: Christian Schneider > Fix For: 1.1.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] [Comment Edited] (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-tabpanel&focusedCommentId=13560574#comment-13560574 ] Christian Schneider edited comment on SYNCOPE-246 at 1/23/13 11:20 AM: --- I just created a new issue for 1.1.0 and linked it. The reason why I moved this issue is that we will not be able to remove the setters for 1.1.0 as we want to be compatible with spring services. was (Author: ch...@die-schneider.net): I just created a new issue for 1.1.0 and linked it. > 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: Christian Schneider > Fix For: 1.1.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] [Created] (SYNCOPE-288) Make setters of Transfer Objects (TO) compatible to CXF and JAXB
Christian Schneider created SYNCOPE-288:
---
Summary: Make setters of Transfer Objects (TO) compatible to CXF
and JAXB
Key: SYNCOPE-288
URL: https://issues.apache.org/jira/browse/SYNCOPE-288
Project: Syncope
Issue Type: Improvement
Components: core
Affects Versions: 1.1.0
Reporter: Christian Schneider
Assignee: Christian Schneider
Fix For: 1.1.0
Like found in issue 231 there is a way to make the setters of TOs work with
CXF. So this issue is to change them to the new style.
public void setOrders(List orders) {
if (this.orders != orders) {
this.orders.clear();
this.orders.addAll(orders);
}
}
--
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 ] Christian Schneider updated SYNCOPE-246: Affects Version/s: (was: 1.1.0) 1.2.0 > 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.2.0 > Environment: CXF branch >Reporter: Andrei Shakirin > Assignee: Christian Schneider > Fix For: 1.1.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] [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-tabpanel&focusedCommentId=13560569#comment-13560569
]
Christian Schneider commented on SYNCOPE-246:
-
The problem is that the setter is called with exactly the same object as the
internal list.
So currently it looks like this:
public void setOrders(List orders) {
this.orders.clear();
this.orders.addAll(orders);
}
If this is called with the internal list object then the result is an empty
list.
I found that we simply need to check if the incoming object is that same as the
internal list and then skip the changes.
public void setOrders(List orders) {
if (this.orders != orders) {
this.orders.clear();
this.orders.addAll(orders);
}
}
So for version 1.1.0 I will change the setters like above. (Will create and
link a new issue for this).
As soon as we completed the switch to cxf and remove the spring services we
still should remove the setters. So I will move this issue to 1.2.0
> 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: Christian Schneider
> Fix For: 1.1.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
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 Set / > Set 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 >
[jira] [Resolved] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SYNCOPE-241. - Resolution: Fixed Assignee: Christian Schneider As moving the tests proved to be quite difficult we keep the persistence inside core for now. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-tabpanel&focusedCommentId=13559504#comment-13559504 ] Christian Schneider commented on SYNCOPE-246: - I will check if it is possible to use spring services and cxf services with the same transfer objects. > 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: Christian Schneider > Fix For: 1.1.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
Re: [Discussion] Rest package names
On 21.01.2013 11:14, Andrei Shakirin wrote: > Hi Christian, > >>> 2. Resource comparators and server exception mapper: >> org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). >> It makes purpose of these classes more clear. >> Generally I don't like util packages. I would put these helpers into the same >> package as the service impls as they are only referenced from there. > They are referenced not from service package, but from spring service > configuration. > Theoretically they can be used with some different service implementations. > Perhaps "helpers" sounds better as "utils"? The classes are referenced from the spring config but they belong to the impl classes so why introduce a new package? > >>> 3. Client exception mapper: org.apache.syncope.client.rest.utils >> (unfortunately cannot be combined with server mapper, because server >> exception mapper have a lot of dependencies of core specific exceptions). >> Why not client.rest? If we keep the client proxy classes in some form we >> could also put it there. > I would like to keep it symmetric with core, otherwise it will be confusing. Makes sense to make it similar to core. That is why I propose to also avoid the util if we avoid it in core. Of course if we choose util in core then it makes sense to do the same on the client side. Christian
Re: [Discussion] Rest package names
On 21.01.2013 10:29, Andrei Shakirin wrote: > Hi, > > I would like to make a proposal regarding some Rest package names: > > 1. Core services implementations: org.apache.syncope.core.services > (actually org.apache.syncope.core.services.impl). "Impl" ending doesn't > bring additional information and doesn't recommended by java best practices. > "rest" is deliberately not in package name, because implementation is > basically independent from Rest and can be potentially reused for other > remote interfaces. Impl is a default name in OSGi to mark the package as private. So I think it is not against best practices. In this special case I agree though as the service api is defined in org.apache.syncope.services. So the core part in org.apache.syncope.core.services is already enough to separate those two packages. > > 2. Resource comparators and server exception mapper: > org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). > It makes purpose of these classes more clear. Generally I don't like util packages. I would put these helpers into the same package as the service impls as they are only referenced from there. > > 3. Client exception mapper: org.apache.syncope.client.rest.utils > (unfortunately cannot be combined with server mapper, because server > exception mapper have a lot of dependencies of core specific exceptions). Why not client.rest? If we keep the client proxy classes in some form we could also put it there. Christian
Re: [Discussion] New REST Service Interfaces - Entitlements
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 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
Re: [Discussion] New REST Service Interfaces - Entitlements
On 17.01.2013 14:43, Fabio Martelli wrote: > Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: > >> 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... > Why not AuthorizationController or AccessController? I'd prefer the first one. > May be this controller will be improved to add access controller features int > the next future (please, take a look at the roadmap). I agree with the names Fabio proposed. If it is planned to put more Authorization stuff in there then it makes sense to not have Entitlement in the name. Like Andrei proposed we should either rename all controllers to Service or none. If we rename them partly people will be confused. >> === Changing response Type === >> listEntitlements() returns a List whereas getEntitlements() returns >> a Set. >> >> 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. > Agree I also agree with Set. > >> 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. Set. >> >> EntitlementTO can be modeled in one of two ways: >> >> Option 1: >> >> ROLE_ADMIN >> ROLE_SUPERUSER >> >> >> Option 2: >> >> >> ROLE_ADMIN >> >> >> ROLE_SUPERUSER >> >> >> >> 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 above. Not sure about this one as I do not know how probable it is that we have more attributes in Entitlement. 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. Christian > >> 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. > Good. > > Regards, > F. >
Re: svn commit: r1434684 - in /syncope/trunk/archetype: pom.xml src/main/resources/archetype-resources/core/src/main/resources/activiticontent.xml src/main/resources/archetype-resources/core/src/main/
On 17.01.2013 15:46, Francesco Chicchiriccò wrote: > On 17/01/2013 15:37, Christian Schneider wrote: >> I added the code to copy them too. I just committed them as they were >> reported changed. Should I delete the files and tell svn to ignore them? > > Just updated svn:ignore + removed again all local archetype resources > from SVN. > I will open an issue to change the resource population for archetype > in order to be more robust to this kind of changes. > >> I found that the AbstractDAOTests can not simply create the Activiti >> properties as the table is not there when we omit the spring xml to >> initialize Activiti. So I wanted to make the ContentLoader more >> flexible. >> This way I was able to replace the xsl based removal of Activiti >> properties by a java based one. I think this is better than xsl as it is >> more obvious to see in the code. It took me a while to see that the xsl >> does this... > Did you take into any account the export procedure for subsequent > re-import when changing this logic? > Have you tried how this behaves in overlays generated from the archetype? > Now we don't have any more a single content.xml (as generated by > export generates) but two separate content.xml and activiticontent.xml > > I will open another issue to verify how export / import procedure will > work after these changes. > Hi Francesco, I am not aware how it works in the archetype. Can you explain shortly how the export works? I thought that we simply use the content.xml as a kind of template in the archetype and people would later simply change it. If it is a bigger issue I can revert the changes. They are not necessary for the issue SYNCOPE-241. Btw. I found that the ImportExport class mixes two things that seem to be quite independent. What do you think about splitting ImportExport into an ImportContent class and an ExportContent class? As far as I understood these functionalities seem to share no code in the ImportExport class. Regards Christian
Re: svn commit: r1434684 - in /syncope/trunk/archetype: pom.xml src/main/resources/archetype-resources/core/src/main/resources/activiticontent.xml src/main/resources/archetype-resources/core/src/main/
I added the code to copy them too. I just committed them as they were reported changed. Should I delete the files and tell svn to ignore them? I found that the AbstractDAOTests can not simply create the Activiti properties as the table is not there when we omit the spring xml to initialize Activiti. So I wanted to make the ContentLoader more flexible. This way I was able to replace the xsl based removal of Activiti properties by a java based one. I think this is better than xsl as it is more obvious to see in the code. It took me a while to see that the xsl does this... Christian On 17.01.2013 15:32, Francesco Chicchiriccò wrote: > On 17/01/2013 15:27, cschnei...@apache.org wrote: >> Author: cschneider >> Date: Thu Jan 17 14:27:33 2013 >> New Revision: 1434684 >> >> URL: http://svn.apache.org/viewvc?rev=1434684&view=rev >> Log: >> SYNCOPE-241 Adding new activiticontent.xml to archetype > > Why this activiticontent.xml? Why removing the XSLT dynamic from core > pom.xml? > > Moreover: please consider that archetype resources must be copied from > core and console as part of the build process and not statically > committed as you've just did for content.xml and activiticontent.xml. > > Regards.
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556110#comment-13556110 ] Christian Schneider commented on SYNCOPE-241: - Just committed the change SYNCOPE-241 Moving PropagationActions back into core.propagation. Created impl package to avoid cycles http://svn.apache.org/viewvc?view=revision&revision=r1434636 Next I will work on the two misplaced sync classes in persistence. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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)
On 17.01.2013 10:05, Francesco Chicchiriccò wrote: > On 17/01/2013 09:13, Jan Bernhardt wrote: > >> 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. > > 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. > > 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)? > Hi, I will explain a bit how our team structure is. Andrei, Jan, Christian Schmüling and me are currently working on a large project that will go for several years. So we are a bit separated from normal product development. Still most we do will go into the open source projects. In fact I am only working 50% on the project and 50% in the Apache Team. The rest of our people is either working on the Apache Team or in our TESB Runtime Team. So while we are working on the same projects we have different management and of course slightly different goals. From the apache team your already know Jean Baptiste and Colm. I fully agree that our internal committment (we are doing scrum) is not always in line with community development and we are aware of that. As syncope is community driven our internal plan of course can only be a proposal for the community. During our project we will be active in different communities over time. So we will not always work on syncope but I am pretty sure that over time we will continue to put considerable efforts into syncope. Christian
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 personally suggest to devote as much > energy as possible towards 1.1.0 release, possibly putting the CXF > migration on hold for a while. > > Regards. >
Re: Missplaced classes?
On 16.01.2013 15:58, Francesco Chicchiriccò wrote: > On 16/01/2013 15:46, Christian Schneider wrote: >> Hi Francesco, >> >> I put these interfaces in the beans package as they are referenced by >> classes in persistence. You are right that they should go to a better >> named package. The problem with core.sync and core.propagation is that >> these packages have heavy dependencies to most other parts of the >> system. > > What if we > 1. move the "missplaced" from core.persistence.beans to core.sync / > core.propagation > 2. move all implementation classes (not interfaces / enums / > exceptions) to new packages core.sync.impl / core.propagation.impl Sounds like a good idea. I just tried this with propagation. The only problem I hit was the ConnectorFactory which references the ConnectorFacadeProxy. Perhaps I can solve this with an interface for this class. Will try it and give you feedback. Christian
Re: Discussion: Persistence module without tests
I think we have a consensus for alternative 1. So I will close the issue and will not apply my last patch. Christian On 15.01.2013 15:58, Christian Schneider wrote: > So I see two alternatives: > > 1. Keep persistence inside core but try to keep it as a separate > architectural layer. This would mean to avoid cycles between persistence > and the rest of core "by hand". > 2. Only move the persistence classes to the persistence module but not > the tests. I created a patch for this in the issue above. > > > > So what do you guys think about this? > > Christian > >
Re: Missplaced classes?
Hi Francesco, I put these interfaces in the beans package as they are referenced by classes in persistence. You are right that they should go to a better named package. The problem with core.sync and core.propagation is that these packages have heavy dependencies to most other parts of the system. So for example SyncActions is referenced by org.apache.syncope.core.persistence.validation.entity.SyncTaskValidator. So if it is moved to core.sync then this will cause a cycle with persistence. SyncResult is referenced by SyncActions. PropagationActions is referenced by org.apache.syncope.core.persistence.validation.entity.ExternalResourceValidator. So basically the validation classes cause the cycles. So I moved these classes / interfaces near classes that have a lot to do with them. Another aproach would be to move validation out of peristence and avoid all references from persistence classes to validation but this is much more difficult to achieve. I have attached the structure 101 diagram of syncope core so you can see the current dependencies. Christian On 16.01.2013 15:10, Francesco Chicchiriccò wrote: > Hi all, > while reviewing some wiki pages, I've unexpectedly found that > PropagationActions, SyncActions and SyncResult were put in package > org.apache.syncope.core.persistence.beans > > This package, as its name suggests, is meant for JPA entities, not for > interfaces having their own package (org.apache.syncope.core.sync and > org.apache.syncope.core.propagation). > > If you don't have objections, I'll move back in the right package. > > Regards. >
Discussion: Persistence module without tests
Hi all, I am currently working on https://issues.apache.org/jira/browse/SYNCOPE-241 . I succeeded in moving the production classes for the persistence layer to a separate module. One interesting last problem I solved there was that spring did not auto detect the entities. I found that the peristence.xml has to be in the same jar as the entities. Only then will spring correctly detect the classes. When trying to also move the persistence tests into the persistence module I faced a lot of problems as our current build only works when the tests are in one module. (See below). I do not see a good way to move the persistence tests right now. With some bigger changes in the way syncope builds and tests this may be possible but it would be to big for me to tackle at the moment. So I see two alternatives: 1. Keep persistence inside core but try to keep it as a separate architectural layer. This would mean to avoid cycles between persistence and the rest of core "by hand". 2. Only move the persistence classes to the persistence module but not the tests. I created a patch for this in the issue above. I personally prefer option 2. While it would be better to have the tests in persistence too it is a good step in the right direction and already has some benefits: - It is impossible to accidently create new dependencies from persistence classes to other parts of core. So persistence is guaranteed to be a inner core of syncope that can be understood on its own - The jpa enhancement happens in persistence. So when you work at core you can leave the persistence project closed and this way eclipse will not accidently overwrite the enhanced classes with the original classes and make your tests fail So what do you guys think about this? Christian The problems I faced: - Persistence test as well as the other core tests have to support a wide range of databases. So this results in a lot of duplication between the poms of core and persistence - The tests require a lot of test resources that are partly changed during the build depending on the profile. So this could also lead to a lot of duplication - I tried to move the test resources into a separate test-resources project. There these resources would then be in src/main/resources to go into the jar to be available to core and persistence. This separate project alone is already a bit ugly. Additionally we have some resources like persistence.properties also in src/main/resources of core. The current tests rely on the fact that src/test/resources override src/main/resources. With a separate test-resources project this does not work anymore.
[jira] [Updated] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-6.patch I have given up to move the persistence tests into the persistence module for now. It is too difficult to do with our current build without creating a lot of duplicated pom content and resources. On the other hand I succeeded in moving at least the production persistence classes into a separate persistence module. There are at least two advantage compared to the current state: - It is impossible to accidently create new dependencies from persistence classes to other parts of core. So persistence is guaranteed to be a inner core of syncope that can be understood on its own - The jpa enhancement happens in persistence. So when you work at core you can leave the persistence project closed and this way eclipse will not accidently overwrite the enhanced classes with the original classes and make your tests fail > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553717#comment-13553717 ] Christian Schneider commented on SYNCOPE-241: - I am currently struggling with actually moving the perisistence into a separate module. The classes and test spring contexts are separated nicely now but the pom.xml changes a lot using ant and I have no idea how to move this part without duplicating a lot of the test resources. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552912#comment-13552912 ] Christian Schneider commented on SYNCOPE-241: - At least I do not know any other way. I think the interface is also no big issue to remove at a later point as long as it is not reused. In any case I think the problem I solved with the interface will be more apparent when I move the classes to their own module as then there is really no way for them to access code in other parts of core. Then we should look at it again and see what alternatives we have. I can open a discussion on dev at this point. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552563#comment-13552563 ] Christian Schneider commented on SYNCOPE-241: - 1. Not sure why the removed comments were missing. I renamed the file to persistenceTestEnv.xml 5. I dont think there is a way to avoid this interface. It is a call back the lower layer persistence offers to the higher layers to hook into processing. I am of course open to any better solution but I do not see any at the moment. Is it ok if I commit at this point and we adjust the UserSuspender later as soon as we find a better solution? > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-5.patch > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552534#comment-13552534 ] Christian Schneider commented on SYNCOPE-241: - 1. I removed the commented out entries. I chose the name as the context is there for the persistence tests. Do you have a better idea how to name it? 2. Removed these 3. I checked the code of loadXml and indeed there are cases where it does not close the inputStream. I added safe close calls to all occurences 4. I removed the ones I found 5. I removed the interfaces for PasswordPolicyEnforcer and AccountPolicyEnforcer as they were indeed only used there. You proposed to consolidate the implementation in AccountPolicyEnforcerImpl. I think this is not possible as the implementation uses classes outside the persistence packages I prepared. Of course we could add these packages but then we would soon end with the whole core in there 6. Renamed the classes > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-4.patch You are right. I forgot to add the files to svn before doing the diff. I added the files and also changed the name of the ActivitiDetector. I can do the commit myself now but I will wait for your feedback. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: (was: SYNCOPE-241-4.patch) > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-4.patch I have finished another step (SYNCOPE-241-4.patch). In this step I did the following: - revert the split of policy into policy and impl as in fact the references to other parts of core were only for suspending users. So I added an interface UserSuspender and implemented it in .workflow.WorkflowUserSuspender - move ContentLoader to persistence.dao.impl and refactored it a bit - Move the workflow related parts out of SpringContextInitializer into WorkflowSetup and ActivityDetector so it does not have too many responsibilities - adjust component-scan in persistenceContext.xml and syncopeContext.xml so they reflect the layers - created testpersistence.xml which contains everything needed by the persistence tests and switch the persistence tests to use only this instead of all the other contexts - Created TestDBInitializer which loads the db content without doing the rest of the SpringContextInitializer tasks So I hope that after this patch I can start to really move the persistence classes to a new persistence module > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241-4.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549695#comment-13549695 ] Christian Schneider edited comment on SYNCOPE-241 at 1/10/13 3:19 PM: -- I had too many problems doing the move in one step so I split this up. In this first patch (SYNCOPE-241-3.patch) I resolve issues where persistence tests refer to do classes outside persistence. This patch does not yet change the spring contexts of the persistence tests or move classes into the persistence module. In detail: - Resolve a new cyclic dependency in SyncActions which should not refer to SyncopeSyncResultHandler which is outside of persistence - Moving the tests that need the PasswordGenerator out of persistence - Switch all persistence tests to a new AbstractDAOTest that is inside peristence to avoid the reference to AbstractTest in core - Moving the TaksTest methods that use TestSyncActions out of persitence into SyncTaskTest as these need stuff outside persistence - Moving the ResoureTest methods that use ResourceDataBinder into a new test class ResourceDataTest outside persistence was (Author: ch...@die-schneider.net): I had too many problems doing the move in one step so I split this up. In this first patch I resolve issues where persistence tests refer to do classes outside persistence. This patch does not yet change the spring contexts of the persistence tests or move classes into the persistence module. In detail: - Resolve a new cyclic dependency in SyncActions which should not refer to SyncopeSyncResultHandler which is outside of persistence - Moving the tests that need the PasswordGenerator out of persistence - Switch all persistence tests to a new AbstractDAOTest that is inside peristence to avoid the reference to AbstractTest in core - Moving the TaksTest methods that use TestSyncActions out of persitence into SyncTaskTest as these need stuff outside persistence - Moving the ResoureTest methods that use ResourceDataBinder into a new test class ResourceDataTest outside persistence > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-3.patch I had too many problems doing the move in one step so I split this up. In this first patch I resolve issues where persistence tests refer to do classes outside persistence. This patch does not yet change the spring contexts of the persistence tests or move classes into the persistence module. In detail: - Resolve a new cyclic dependency in SyncActions which should not refer to SyncopeSyncResultHandler which is outside of persistence - Moving the tests that need the PasswordGenerator out of persistence - Switch all persistence tests to a new AbstractDAOTest that is inside peristence to avoid the reference to AbstractTest in core - Moving the TaksTest methods that use TestSyncActions out of persitence into SyncTaskTest as these need stuff outside persistence - Moving the ResoureTest methods that use ResourceDataBinder into a new test class ResourceDataTest outside persistence > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, > SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539249#comment-13539249 ] Christian Schneider commented on SYNCOPE-241: - I will take care of the issues and submit a new patch. One question about 5. I listed the classes as I got errors if I do not list them. Can you give some details how spring is used to inject the classes. Perhaps I need to adapt the mechanism. About moving the dao impl and the tests: Will it be ok if I move all db related profiles to the new persistence module? So only the app server related profiles stay in core? > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241-2.patch Created a new patch based on the current trunk. I was able to run the enhance step without a db connection and detailed mapping informations which I think is good. For the main persistence.xml I had to add class elements for all entities as they do not seem to be automatically recognized after the move. > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241-2.patch, SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538130#comment-13538130 ] Christian Schneider commented on SYNCOPE-241: - I found that I did not have the most current trunk when I created the patch. Currently I am testing if I can somehow avoid to have a complete db connection when enhancing the classes.But I get errors like below in the tests. Any idea what that means? In the logs I see that ExternalResource was enhanced. Do you know what the openjpa maven plugin does and why it needs the db connection? at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'springContextInitializer' defined in file [/home/cschneider/checkout/syncope/core/target/classes/org/apache/syncope/core/init/SpringContextInitializer.class]: Invocation of init method failed; nested exception is org.apache.openjpa.persistence.ArgumentException: An error occurred while parsing the query filter "SELECT e FROM ExternalResource e". Error message: The name "ExternalResource" is not a recognized entity or identifier. Perhaps you meant ExternalResource, which is a close match. Known entity names: [AbstractSchema, ExternalResource, RAttrUniqueValue, AbstractVirAttr, Membership, TaskExec, SyncopeConf, Report, RAttr, AbstractExec, SyncopeLogger, USchema, MAttr, PasswordPolicy, RSchema, MSchema, AbstractMappingItem, MAttrValue, MAttrUniqueValue, AbstractAttr, AbstractDerSchema, AbstractVirSchema, UAttr, AccountPolicy, RAttrValue, UAttrValue, ReportExec, SyncopeUser, ConnInstance, AbstractDerAttr, AbstractAttrValue, SyncopeRole, UMappingItem, AbstractMapping, SyncPolicy, RMapping, Policy, ReportletConfInstance, Task, RMappingItem, UAttrUniqueValue, Entitlement, UMapping] > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core > Affects Versions: 1.0.3-incubating >Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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 UserService Interface and switch tests and console to use it
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537806#comment-13537806 ] Christian Schneider commented on SYNCOPE-259: - We could do the change in one issue but I prefer to do it in small steps. As we are not really changing the service implementation I think we can change each Service separately. > Create UserService Interface and switch tests and console to use it > --- > > Key: SYNCOPE-259 > URL: https://issues.apache.org/jira/browse/SYNCOPE-259 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.1.0 > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-259.patch > > > As preparation of the change to use cxf instead of spring webservices this > issue is to introduce a service interface UserService. > The UserService interface should later be used in the core to provide the > UserController and on the console to access the service remotely. > To make the transition easier the idea is to already introduce the interface > upfront and change all tests and the console to use it. Before the switch the > implementation of the interface will simply use the restTemplate under the > covers. -- 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: CXF REST migration plan
I just added the patch for SYNCOPE-241. The separation of the API seems to work fine. I also added an issue https://issues.apache.org/jira/browse/SYNCOPE-259 to track introducing a UserService and switch the tests and client code to it. As you see from the UserTestITCase the change is quite small. I only added the JAXRS API and was able to switch the test without touching any other code. I think that the interface would even make sense if we would not intend to switch to CXF as it removes a lot of repetitive use of the RestTemplate and makes the test more readable. As a next step I will do the change on the console module and the other tests that use the user rest service. Christian On 21.12.2012 10:09, Francesco Chicchiriccò wrote: > On 21/12/2012 09:59, Christian Schneider wrote: >> Hi Francesco, >> >> it is a good idea to release a 1.1.0 version before we introduce the cxf >> depdendencies. >> >> What parts of our plan do you think can go into trunk and what should >> wait till after the 1.1.0 release? >> >> My proposal is this: >> >> On 20.12.2012 17:08, Francesco Chicchiriccò wrote: >>> On 20/12/2012 16:44, Andrei Shakirin wrote: >>>> Hi, >>>> >>>> We just finished CXF migration POC for users and roles: it is >>>> successful and we approximately know how much efforts we need for >>>> complete migration. >>>> I would like to discuss the steps we are going to do for complete >>>> migration in next year. >>>> >>>> >>>> 1. Prerequisites >>>> >>>> a) Finishing persistence refactoring >>>> (https://issues.apache.org/jira/browse/SYNCOPE-241, >>>> https://issues.apache.org/jira/browse/SYNCOPE-242 ) >> Before 1.1.0 > > Agreed, especially because SYNCOPE-242 is already fixed ;-) > >>>> b) Resolve ConnId CXF dependencies problem >>>> (https://issues.apache.org/jira/browse/SYNCOPE-251 ) >> After 1.1.0 > > Agreed. > >>>> 2. Steps >>>> >>>> a) Introduce interfaces for all controllers in >>>> org.apache.syncope.core.rest.controller (the same way as for user and >>>> role in cxf branch). Interfaces will contain JAX-RS annotations. >>>> Commit interfaces to trunk >>>> >> Before 1.1.0 (if time permits) >>>> b) Provide temporary implementation of interfaces (step a) for >>>> "old" spring based rest implementation (based on spring >>>> restTemplate). Commit implementations to trunk >>>> >> Before 1.1.0 (if time permits) >>>> c) Refactor core rest integration tests to use controller >>>> interfaces instead restTemplate. All rest tests must be successful. >>>> Commit refactored tests to trunk. This step helps to prepare tests to >>>> be used with CXF without breaking them >>>> >> Before 1.1.0 (if time permits) > > Agreed only if the whole step 2 (a, b and c) is done at once and if > additional dependencies are very limited (only for JAX-RS annotations). > Otherwise, the whole step 2 should be moved after 1.1.0. > >> All the rest should be delayed till after 1.1.0 >>>> d) Add CXF dependencies, CXF Rest service configuration, >>>> exception mappers and jaxb/json providers, but do not activate them. >>>> Commit them to trunk >>>> >>>> e) Update TO classes for JAXB marshalling (if necessary) and >>>> keep spring marshalling working with the same TO classes. Commit it >>>> to trunk. If keeping JAXB marshalling parallel to spring is too >>>> complicate, this step will be done in cxf-migration branch after step >>>> (f) >>>> >>>> f) Create cxf-migration branch >>>> >>>> g) Activate using CXF Rest for controller interfaces instead >>>> temporary spring based implementation created on step (b). Fix >>>> possible problems >>>> >>>> h) Update console to use CXF Rest. Fix possible problems >>>> >>>> i)Merge cxf-migration branch with trunk >>>> >>>> Our idea is to keep cxf-migration branch possibly short time, split >>>> migration on some small steps and keep the tests and whole system >>>> running in between. >>>> Does this plan make sense? Any other suggestions / ideas? >> Basically my proposal is to put into 1.1.0 all steps that have a low >> risk and provide some benefits. I think it will be good to convert a lot >> of the tests beforehand to the interfaces as this will make it easier to >> backport changes >> to 1.1.x later. >> >> Apart from the above things what is the plan for 1.1.0? Is it feature >> complete already or do you want to get some more features in? > > As wrote yesterday, we should review all issues currently targeted to > 1.1.0 and decide whether to keep or move to next releases. > > Regards. >
[jira] [Updated] (SYNCOPE-259) Create UserService Interface and switch tests and console to use it
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-259: Attachment: SYNCOPE-259.patch Added patch to introduce the UserService interface and switch the UserTestITCase to it. > Create UserService Interface and switch tests and console to use it > --- > > Key: SYNCOPE-259 > URL: https://issues.apache.org/jira/browse/SYNCOPE-259 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.1.0 > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-259.patch > > > As preparation of the change to use cxf instead of spring webservices this > issue is to introduce a service interface UserService. > The UserService interface should later be used in the core to provide the > UserController and on the console to access the service remotely. > To make the transition easier the idea is to already introduce the interface > upfront and change all tests and the console to use it. Before the switch the > implementation of the interface will simply use the restTemplate under the > covers. -- 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] [Created] (SYNCOPE-259) Create UserService Interface and switch tests and console to use it
Christian Schneider created SYNCOPE-259: --- Summary: Create UserService Interface and switch tests and console to use it Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.1.0 Reporter: Christian Schneider Fix For: 1.1.0 As preparation of the change to use cxf instead of spring webservices this issue is to introduce a service interface UserService. The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: SYNCOPE-241.patch Added patch to create a new module persistence-api and move the api classes there. The impl still stays in core. The patched trunk should build fine with it. I am not fully sure about the spring-peristence.xml and orm.xml* files. Ideally I would like to only do the class enhancement in the persistence-api. It seemed as it needs these files to run. It would be great if this could be slimmed down as I think class enhancement should not be dependent on the used db or db config. Any ideas how to do this? > Move persistence and persistence impl into separate modules > --- > > Key: SYNCOPE-241 > URL: https://issues.apache.org/jira/browse/SYNCOPE-241 > Project: Syncope > Issue Type: Improvement > Components: core >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-241.patch > > > The core module currently contains many parts of syncope. This makes it > bigger and more complex than necessary. > A possible modularization is to move the internal model > (org.apache.syncope.core.persistence*) and the persistence impl > (org.apache.syncope.core.persistence.impl) out of core and into separate > modules. > One big advantage would be that the jpa code enhancements would then run in > the model module only. Currently we run into some problems in the cxf > migration when running the rest itests in core that may be caused by eclipse > overwriting the enhanced classes with plain classes. If the model > (peristence) classes are in a separate module we could leave it out of > eclipse and so this would be no issue anymore. > Another advantage would be that the persistence tests could run in the > persistence impl module so when working on the core they would not have to > run each time. -- 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: CXF REST migration plan
Hi Francesco, it is a good idea to release a 1.1.0 version before we introduce the cxf depdendencies. What parts of our plan do you think can go into trunk and what should wait till after the 1.1.0 release? My proposal is this: On 20.12.2012 17:08, Francesco Chicchiriccò wrote: > On 20/12/2012 16:44, Andrei Shakirin wrote: >> Hi, >> >> We just finished CXF migration POC for users and roles: it is >> successful and we approximately know how much efforts we need for >> complete migration. >> I would like to discuss the steps we are going to do for complete >> migration in next year. >> >> >> 1. Prerequisites >> >> a) Finishing persistence refactoring >> (https://issues.apache.org/jira/browse/SYNCOPE-241, >> https://issues.apache.org/jira/browse/SYNCOPE-242 ) Before 1.1.0 >> >> b) Resolve ConnId CXF dependencies problem >> (https://issues.apache.org/jira/browse/SYNCOPE-251 ) >> >> After 1.1.0 >> >> 2. Steps >> >> a) Introduce interfaces for all controllers in >> org.apache.syncope.core.rest.controller (the same way as for user and >> role in cxf branch). Interfaces will contain JAX-RS annotations. >> Commit interfaces to trunk >> Before 1.1.0 (if time permits) >> b) Provide temporary implementation of interfaces (step a) for >> "old" spring based rest implementation (based on spring >> restTemplate). Commit implementations to trunk >> Before 1.1.0 (if time permits) >> c) Refactor core rest integration tests to use controller >> interfaces instead restTemplate. All rest tests must be successful. >> Commit refactored tests to trunk. This step helps to prepare tests to >> be used with CXF without breaking them >> Before 1.1.0 (if time permits) All the rest should be delayed till after 1.1.0 >> d) Add CXF dependencies, CXF Rest service configuration, >> exception mappers and jaxb/json providers, but do not activate them. >> Commit them to trunk >> >> e) Update TO classes for JAXB marshalling (if necessary) and >> keep spring marshalling working with the same TO classes. Commit it >> to trunk. If keeping JAXB marshalling parallel to spring is too >> complicate, this step will be done in cxf-migration branch after step >> (f) >> >> f) Create cxf-migration branch >> >> g) Activate using CXF Rest for controller interfaces instead >> temporary spring based implementation created on step (b). Fix >> possible problems >> >> h) Update console to use CXF Rest. Fix possible problems >> >> i)Merge cxf-migration branch with trunk >> >> Our idea is to keep cxf-migration branch possibly short time, split >> migration on some small steps and keep the tests and whole system >> running in between. >> Does this plan make sense? Any other suggestions / ideas? > Basically my proposal is to put into 1.1.0 all steps that have a low risk and provide some benefits. I think it will be good to convert a lot of the tests beforehand to the interfaces as this will make it easier to backport changes to 1.1.x later. Apart from the above things what is the plan for 1.1.0? Is it feature complete already or do you want to get some more features in? Best regards Christian
[jira] [Commented] (SYNCOPE-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536076#comment-13536076 ] Christian Schneider commented on SYNCOPE-242: - Many thanks ... looks good > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider >Assignee: Jean-Baptiste Onofré > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-3.patch, SYNCOPE-242-fromtgz.patch, syncope_core_after.png, > syncope_core_before.png, syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-251) Fix Dependency issues with ConnID Bundle deployment
[ https://issues.apache.org/jira/browse/SYNCOPE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13535827#comment-13535827 ] Christian Schneider commented on SYNCOPE-251: - I also thought about switching off the special classloading. This may be the simplest solution. Should I provide a patch for ConnId with this? > Fix Dependency issues with ConnID Bundle deployment > > > Key: SYNCOPE-251 > URL: https://issues.apache.org/jira/browse/SYNCOPE-251 > Project: Syncope > Issue Type: Sub-task > Components: core > Environment: Linked issue on ConnId: > http://code.google.com/p/connid/issues/detail?id=55 >Reporter: Jan Bernhardt >Assignee: Jan Bernhardt > Fix For: 1.2.0 > > Attachments: cxf-deps.patch > > > SOAP ConnID Bundle contains CXF dependencies, which cause Classloading issues > when migrating Syncope to CXF, > Currently maven-dependency-plugin:copy is used to generate bundle jars, but > this plugin does not support to exclude transitive dependencies. Maybe > another maven plugin (maven-assembly-plugin ?) can be used to exclude CXF > dependencies from SOAP ConnID Bundle. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-242: Attachment: SYNCOPE-242-3.patch Patch to move SyncopeUserValidator back into validation.entity as it is referenced from the @SyncopeUserCheck annotation. Decoupling policy impl from policy api so the validator only needs to reference the policy enforcer interfaces. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider >Assignee: Jean-Baptiste Onofré > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-3.patch, SYNCOPE-242-fromtgz.patch, syncope_core_after.png, > syncope_core_before.png, syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reopened SYNCOPE-242: - Found a new issue like described in my previous comment. Will attach a patch > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider >Assignee: Jean-Baptiste Onofré > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, > syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534056#comment-13534056 ] Christian Schneider commented on SYNCOPE-242: - Thanks for applying the patch. When trying to move the peristence api into a separate module I found that we can not leave the SyncopeUserValidator out of the peristence API. It is used in the constraint @Constraint(validatedBy = SyncopeUserValidator.class) of the @SyncopeUserCheck annotation. As the SyncopeUserValidator needs the Account- and PasswordPolicyEnforcers we have to find a way to make these also (at least partly move to the api. I found a way to make this work by spearating the interface of the Enforcers from the impls. So the SyncopeUserValidator only needs to reference the interfaces which can then move to the api. Should I open a new issue for this or should I just add a patch for it? > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider >Assignee: Jean-Baptiste Onofré > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, > syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530918#comment-13530918 ] Christian Schneider commented on SYNCOPE-242: - Hi Francesco. Should I create a working patch or can you just use the one you created from my tgz. I think it contains all changes I planned. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, > syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530016#comment-13530016 ] Christian Schneider commented on SYNCOPE-242: - Many thanks for helping us with that. I was able to recreate a working patch in the way you described. I only found that I have to do one additional thing. I had to add the new interfaces I created to svn before creating the patch else they were not included > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, > syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-242: Attachment: syncope.tgz Corrected the component-scan config > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > syncope_core_after.png, syncope_core_before.png, syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-242: Attachment: (was: syncope.tgz) > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > syncope_core_after.png, syncope_core_before.png > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-242: Attachment: syncope.tgz I created a tgz of my checkout. Not sure if this helps but perhaps we can see the difference. If you want you can also send me yours and I will check for differences. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > syncope_core_after.png, syncope_core_before.png, syncope.tgz > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529954#comment-13529954 ] Christian Schneider commented on SYNCOPE-242: - I tried to apply my patch to a clean trunk with the command above. I also had to skip the moved files. In the end it reported 1 hunk. Then when I compiled I got a lot of errors (see below). So I assume the way I created or applied the patch is somehow wrong. For creating the patch I used Team -> Create Patch in eclipse. What is the recommended way to create a patch on the command line? I also tried with svn diff > SYNCOPE-242-2.patch but had the same issues. Any idea what I am doing wrong? Christian - [INFO] Compiling 289 source files to /home/cschneider/checkout/syncope2/core/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/persistence/beans/user/SyncopeUser.java:[65,36] cannot find symbol symbol : class PasswordEncoder location: package org.apache.syncope.core.util [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeUserCheck.java:[29,47] package org.apache.syncope.core.validation.user does not exist [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/workflow/WorkflowAdapter.java:[36,21] cannot find symbol symbol : class WorkflowLoader location: interface org.apache.syncope.core.workflow.WorkflowAdapter [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/persistence/dao/RoleDAO.java:[48,82] cannot find symbol symbol : class InvalidSearchConditionException location: interface org.apache.syncope.core.persistence.dao.RoleDAO [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/persistence/dao/AttributableDAO.java:[36,47] cannot find symbol symbol : class InvalidSearchConditionException location: interface org.apache.syncope.core.persistence.dao.AttributableDAO [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/persistence/dao/UserDAO.java:[36,82] cannot find symbol symbol : class InvalidSearchConditionException location: interface org.apache.syncope.core.persistence.dao.UserDAO [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/controller/RoleController.java:[31,38] cannot find symbol symbol : class ConnObjectUtil location: package org.apache.syncope.core.connid [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/controller/RoleController.java:[36,47] cannot find symbol symbol : class InvalidSearchConditionException location: package org.apache.syncope.core.persistence.dao [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/data/RoleDataBinder.java:[27,38] cannot find symbol symbol : class ConnObjectUtil location: package org.apache.syncope.core.connid [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/propagation/PropagationManager.java:[34,38] cannot find symbol symbol : class ConnObjectUtil location: package org.apache.syncope.core.connid [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/controller/RoleController.java:[98,13] cannot find symbol symbol : class ConnObjectUtil location: class org.apache.syncope.core.rest.controller.RoleController [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/controller/RoleController.java:[204,20] cannot access org.apache.syncope.core.rest.controller.InvalidSearchConditionException bad class file: /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/controller/InvalidSearchConditionException.java file does not contain class org.apache.syncope.core.rest.controller.InvalidSearchConditionException Please remove or make sure it appears in the correct subdirectory of the classpath. [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/data/RoleDataBinder.java:[55,13] cannot find symbol symbol : class ConnObjectUtil location: class org.apache.syncope.core.rest.data.RoleDataBinder [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java:[31,38] cannot find symbol symbol : class ConnObjectUtil location: package org.apache.syncope.core.connid [ERROR] /home/cschneider/checkout/syncope2/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java:[49,36] cannot find symbol symbol : class PasswordEncoder location: package org.apache.syncope.core.util [ERR
[jira] [Updated] (SYNCOPE-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-242: Attachment: SYNCOPE-242-2.patch Moved connutils to connid > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, > syncope_core_after.png, syncope_core_before.png > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529856#comment-13529856 ] Christian Schneider edited comment on SYNCOPE-242 at 12/12/12 11:27 AM: Hi JB. I simply unassigned the issue as I did not see you on skype and the refactoring is a bit time critical for us as we are waiting with the switch to cxf till this issue is done. Are you currently also working on a patch to this or did you simply want to apply my patch? was (Author: ch...@die-schneider.net): Hi JB. I simply unassigned the issue as I did not see you on skype and the refactoring is a bit time critical for us as we are waiting with the switch to cxf till this issue is done. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, syncope_core_after.png, > syncope_core_before.png > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529856#comment-13529856 ] Christian Schneider commented on SYNCOPE-242: - Hi JB. I simply unassigned the issue as I did not see you on skype and the refactoring is a bit time critical for us as we are waiting with the switch to cxf till this issue is done. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, syncope_core_after.png, > syncope_core_before.png > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529845#comment-13529845 ] Christian Schneider commented on SYNCOPE-242: - I just looked into the issue with PasswordGenerator. The problem is that it references policy which then references rest, workflow and propagation. So as the util package is heavily used in persistence I had to make sure that I move any classes out of util that need anything else than persistence. > Resolve dependency cycles between persistence and the rest of syncope core > -- > > Key: SYNCOPE-242 > URL: https://issues.apache.org/jira/browse/SYNCOPE-242 > Project: Syncope > Issue Type: Improvement >Affects Versions: 1.0.3-incubating > Reporter: Christian Schneider > Fix For: 1.1.0 > > Attachments: SYNCOPE-242-1.patch, syncope_core_after.png, > syncope_core_before.png > > > When analysing if we could move the persistence and persistence impl into > separate modules I found that there are a lot of dependency cycles in the > syncope core module. I have added a structure 101 diagram of the cycles to > the issue so you can take a look. > Especially the cycles between persistence and the rest of core are important > as they prevent us from moving these packages out of core. > I have already done some experimentations how to solve the cycles and am > pretty sure I can fix that. -- 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
