Re: Jena3 : status? think about a release?

[Claude Warren]

I posted a note recently about an epic or story to ensure that we get the
major documentation updated.  With the size of the 2->3 change I think we
need to provide documentation.  I have some started for the security
section and Bruno pointed me to a skeleton page for the rest but I think
the documentation needs to be completed before release.

Perhaps it makes sense to create an epic for the release where we can hang
all the tasks that need to be completed as an easy way to track them.

I was wondering how to do the update of the documentation in a way that
does not step on the current documentation.

Claude

On Sun, Jul 19, 2015 at 7:07 PM, Andy Seaborne  wrote:

> How is it going? We seem to have converged for JENA-990 now and the
> jena-core/jena-permissions split feels reasonable.
>
> The PR backlog is reduced, though #47 is still outstanding.
>
> Doing RC1 of a release this week would fit well for me.  And hopefully,
> enough bandwidth to create a clean maven repository.
>
> Comments?
>
> Andy
>
>
> On 14/07/15 15:01, Andy Seaborne wrote:
>
>> Works for me.
>>
>> If any changes to jena-core can be done first, we can make sure things
>> are stable and also not overlap.
>>
>> It'll take me a few days to clear what backlog I can, or assess that
>> just before a release is not a good time for a change.
>>
>> + Documentation bulk changes done (by the power of "perl -i").
>>
>> + AnonId done.
>>
>> (It seems that PRs are not always getting closed/mark merged on github -
>> I haven't found the common factor - #80 and #86 aren't behaving, maybe
>> it just taking a very long time to propagate)
>>
>>  Andy
>>
>> On 14/07/15 10:45, Claude Warren wrote:
>>
>>> I would like to get JENA-990 (Rename UpdateDeniedException) into Jena3
>>> I would also like to clean up the permissiosn system so that it uses the
>>> exceptions described in JENA-990 and I would like to clean up the
>>> node/triple handling.  the Permissions code was originally designed to be
>>> graph implementaiton agnostic.  So there is a layer of complexity that
>>> can
>>> be removed and should make it faster.
>>>
>>> I started work on 990 yesterday.  I think I can have all of the above
>>> completed by end of week. (Unit tests included)
>>>
>>> Claude
>>>
>>> On Mon, Jul 13, 2015 at 4:36 PM, Andy Seaborne  wrote:
>>>
>>>  After some build-wrestling today, I am hopeful we can do a Jena3 release
 soon.

 There are a few things I know need doing:

 1. Documentation : com.hp.hpl.jena => org.apache.jena

 This is a bulk change - except for [1] !!
 Add a big statement to the front page linking to the migration page.

 2. AnonId (JENA-986, JENA-987)

 This removes a linkage between the core of the core (graph) and the RDF
 API. There is PR#86 for this.


 As time and understanding permits I will try to process other PRs as
 well.

 I'd very much like to get #82 (JENA-979) in.

 (#47 / JENA-901 / LPDRuleEngine) could do with another review - there
 is a
 bit labelled FIXME)

 I have a bit of time this month so I'm able to RM the release.

 What else must be done before we can go for Jena 3.0.0?

 Closing any JIRA that are done (thanks Claude for the recent batch) is
 helpful.

  Andy

 [1]
 http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html



>>>
>>>
>>
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Jena3 : status? think about a release?

[Andy Seaborne]

How is it going? We seem to have converged for JENA-990 now and the 
jena-core/jena-permissions split feels reasonable.


The PR backlog is reduced, though #47 is still outstanding.

Doing RC1 of a release this week would fit well for me.  And hopefully, 
enough bandwidth to create a clean maven repository.


Comments?

Andy

On 14/07/15 15:01, Andy Seaborne wrote:

Works for me.

If any changes to jena-core can be done first, we can make sure things
are stable and also not overlap.

It'll take me a few days to clear what backlog I can, or assess that
just before a release is not a good time for a change.

+ Documentation bulk changes done (by the power of "perl -i").

+ AnonId done.

(It seems that PRs are not always getting closed/mark merged on github -
I haven't found the common factor - #80 and #86 aren't behaving, maybe
it just taking a very long time to propagate)

 Andy

On 14/07/15 10:45, Claude Warren wrote:

I would like to get JENA-990 (Rename UpdateDeniedException) into Jena3
I would also like to clean up the permissiosn system so that it uses the
exceptions described in JENA-990 and I would like to clean up the
node/triple handling.  the Permissions code was originally designed to be
graph implementaiton agnostic.  So there is a layer of complexity that
can
be removed and should make it faster.

I started work on 990 yesterday.  I think I can have all of the above
completed by end of week. (Unit tests included)

Claude

On Mon, Jul 13, 2015 at 4:36 PM, Andy Seaborne  wrote:


After some build-wrestling today, I am hopeful we can do a Jena3 release
soon.

There are a few things I know need doing:

1. Documentation : com.hp.hpl.jena => org.apache.jena

This is a bulk change - except for [1] !!
Add a big statement to the front page linking to the migration page.

2. AnonId (JENA-986, JENA-987)

This removes a linkage between the core of the core (graph) and the RDF
API. There is PR#86 for this.


As time and understanding permits I will try to process other PRs as
well.

I'd very much like to get #82 (JENA-979) in.

(#47 / JENA-901 / LPDRuleEngine) could do with another review - there
is a
bit labelled FIXME)

I have a bit of time this month so I'm able to RM the release.

What else must be done before we can go for Jena 3.0.0?

Closing any JIRA that are done (thanks Claude for the recent batch) is
helpful.

 Andy

[1]
http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html

Re: JENA-955 and other documentation

[Andy Seaborne]

On 19/07/15 09:59, Bruno P. Kinoshita wrote:

Thought I had seen somewhere a link about a doc for migrating from Jena 2 to 
Jena 3.
http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html
Maybe this could be the main page for the migration, and link to other pages as 
the security/permissions module?
Bruno


Yes - hopefully, that page can capture what the vast majority of 
applications need to know without swamping them in details for things 
they will not encounter.  It works for code I've upgraded.  Code that 
deals with deep internals (which is not "application code" to me) may 
find other things - someone mentioned GraphStore to me (that's on the 
page anyway).  Details of internal changes would be a cause swamping; we 
have JIRA as well.


If jena-permissions is has some specific changes, they should do in its 
documentation.  I think it makes them clearer to put them in context.


We can refine this documentation as well - changes can be made to 
reflect user feedback.


Andy




   From: Claude Warren 
  To: dev@jena.apache.org
  Sent: Sunday, July 19, 2015 7:45 PM
  Subject: JENA-955 and other documentation

There is an issue opened by Bruno (JENA-955) that is for updating the Jena
Security documentation to Jena Permissions.

I think given the breadth of the changes that are in place between 2.x and
3.0 we should have a page of migration/upgrade instructions, possibly with
sub pages for any components (like permissions) that have more complex
changes.

I think this is a story or an epic and should be created and executed
before the release of 3.0

I think that we will need to branch the documentation in SVN to perform
these changes as we don't want to affect the production site and any
potential contributions there.

Thoughts?
Claude

Re: Final Deliveries of GSoC Project (JENA-491)

[Andy Seaborne]

Qihong,

I hope the exams have gone well.

All of the tasks include "delivery" and it is this aspect we need to 
concentrate on now.


There needs to be:

1. Code and grammar changes
2. Tests
3. Pull requests
4. Documentation

I've looked through https://github.com/confidencesun/jena/commits/JENA-491.

(1) seems to progressing well.

For (2) I don't see tests in ARQ, whereas there should be execution and 
syntax test. There are 2 tests in Fusek2/TestQuery.


For (3), it is going to need some preparation.

There is a problem with the last (July 5) commit. At a guess, it looks 
like you updated the source code and committed it rather than merge the 
commits from Jena.


https://github.com/confidencesun/jena/commit/07afdbf0fe635d41c302b25a9c51f43802ea903a

There are 341 changed files.

Pull requests sent to apache/jena will need to be your code.

http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3C559EF342.3010806%40apache.org%3E

We need separate pull requests for jena-arq and one for jena-fuseki2. If 
we can start with jena-arq we can have review and refinement of that 
happening while work on pull requests for jena-fuseki2 happens.


Is there anymore work needed, except for tests, on the jena-arq module?

Andy

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-990:


That now makes sense, thanks

>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-990:


I think OperationDeniedException has at least 3 children
AccessDeniedException -- parent of more specific reasons
AuthenticationRequriedException -- no credentials are available for permissions 
assessment.
CannotCreateException -- an existing exception used in a test case but an 
example of another case none the less.

AccessDeniedException --parent of 
AddDeniedException
DeleteDeniedException
ReadDeniedException
UpdateDeniedException

Fuseki should respond to:
AccessDeniedException with 403 Forbidden - The server understood the request, 
but is refusing to fulfill it. Authorization will not help and the request 
SHOULD NOT be repeated.

AuthenticationRequiredException with 401 Unauthorized -The request requires 
user authentication. 

Other OperationDeniedExceptions with 400 Bad Request - The request could not be 
understood by the server due to malformed syntax.  Though a arguably it could 
be a 500 series response.






>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-990) rename the UpdateDeniedException

[Andy Seaborne (JIRA)]

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

Andy Seaborne edited comment on JENA-990 at 7/19/15 10:58 AM:
--

> Basically if the graph is read-only authentication will not solve the add 
> denied exception – right?

Yes, a read-only graph is not a (necessarily) security issue. Hence:

I think the "AccessDeniedException" I suggested is what you call 
AuthenticationRequiredException.

I haven't see a case of a situation which is OperationDeniedException but not 
AccessDeniedException and it seems there is redundancy:

OperationDeniedException > AddDeniedException
OperationDeniedException > DeleteDeniedException
OperationDeniedException > AuthenticationRequiredException

Should there be an PermissionsFailedException to go with 
AuthenticationRequiredException?  PermissionsFailedException means that 
authentication says no. AuthenticationRequiredException means ask for 
authentication.

AuthenticationRequiredException => 403
PermissionsFailedException => 401

AddDeniedException, and all  OperationDeniedException, means => "Can't" which 
would be 400 (the best choice in HTTP).


was (Author: andy.seaborne):
> Basically if the graph is read-only authentication will not solve the add 
> denied exception – right?

Yes, a read-only graph is not a (necessarily) security issue. Hence:

I think the The "AccessDeniedException" I suggested is what you call 
AuthenticationRequiredException.

I haven't see a case of a situation which is OperationDeniedException but not 
AccessDeniedException and it seems there is redundancy:

OperationDeniedException > AddDeniedException
OperationDeniedException > DeleteDeniedException
OperationDeniedException > AuthenticationRequiredException

Should there be an PermissionsFailedException to go with 
AuthenticationRequiredException?  PermissionsFailedException means that 
authentication says no.

AuthenticationRequiredException => 403
PermissionsFailedException => 401

AddDeniedException => "Can't": not a security issue => 400

>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-990) rename the UpdateDeniedException

[Andy Seaborne (JIRA)]

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

Andy Seaborne edited comment on JENA-990 at 7/19/15 10:48 AM:
--

> Basically if the graph is read-only authentication will not solve the add 
> denied exception – right?

Yes, a read-only graph is not a (necessarily) security issue. Hence:

I think the The "AccessDeniedException" I suggested is what you call 
AuthenticationRequiredException.

I haven't see a case of a situation which is OperationDeniedException but not 
AccessDeniedException and it seems there is redundancy:

OperationDeniedException > AddDeniedException
OperationDeniedException > DeleteDeniedException
OperationDeniedException > AuthenticationRequiredException

Should there be an PermissionsFailedException to go with 
AuthenticationRequiredException?  PermissionsFailedException means that 
authentication says no.

AuthenticationRequiredException => 403
PermissionsFailedException => 401

AddDeniedException => "Can't": not a security issue => 400


was (Author: andy.seaborne):
> Basically if the graph is read-only authentication will not solve the add 
> denied exception – right?

Yes, a rtead-only graph is not a security issue. Hence:

OperationDeniedException > AddDeniedException
OperationDeniedException > DeleteDeniedException
OperationDeniedException > AuthenticationRequiredException

I haven't see a case of a situation which is OperationDeniedException but not 
AccessDeniedException.  I think the The "AccessDeniedException" I suggested is 
what you call AuthenticationRequiredException.

>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-990:


> Basically if the graph is read-only authentication will not solve the add 
> denied exception – right?

Yes, a rtead-only graph is not a security issue. Hence:

OperationDeniedException > AddDeniedException
OperationDeniedException > DeleteDeniedException
OperationDeniedException > AuthenticationRequiredException

I haven't see a case of a situation which is OperationDeniedException but not 
AccessDeniedException.  I think the The "AccessDeniedException" I suggested is 
what you call AuthenticationRequiredException.

>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-990:


> If Fuseki is going to respond to them distinctly

That's a rather big "if".  All Fuseki can do is 401 or 403, together with 
passing authentication tokens downwards.  It is not going to be sensitive to 
the kind of operation (if it were, it would be a security framework itself). It 
needs to be told whether to engage in HTTP authentication and make the outcomes 
accessible.


>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-990:
--

Commit 4723a8a72cec322ee414dfee4b3d0cd027a8550e in jena's branch 
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=4723a8a ]

Fixed mock conflict in SecuredItemImplTest.
part of the fix for JENA-990


>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-990:
--

Commit 232951d91772e61db65d836b89f54742daaf0bd8 in jena's branch 
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=232951d ]

Added missing licenses
Part of the fix for JENA-990


>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-990:
--

Commit 2cd87b4c151ac2eb0a9f004a4543fd238c26c04f in jena's branch 
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=2cd87b4 ]

Moved permission exceptions into jena-core so they can be included by Fuseki 
and other applications that may need to respond to them.
Part of the fix for issue JENA-990


>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-992) Refactor graph/permissions interface layer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-992:
--

Commit 1dd6cfd1b9b1457af7a7942cd9912c75852c1280 in jena's branch 
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=1dd6cfd ]

initial changes on perm-interface-refactor as part of fix for JENA-992


> Refactor graph/permissions interface layer
> --
>
> Key: JENA-992
> URL: https://issues.apache.org/jira/browse/JENA-992
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Security
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>
> The jena-permissions package was originally designed to be graph 
> implementation agnostic.  To that end there is a layer that translates the 
> jena based node, triple and statement objects into a slightly different 
> format.  As jena-permissions is now part of Apache Jena proper this layer 
> should be factored out to improve performance.
> The results of this refactoring will be visible and probably disruptive to 
> early adopters and so should be done as part of the 3.0 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: JENA-955 and other documentation

[Bruno P. Kinoshita]

Thought I had seen somewhere a link about a doc for migrating from Jena 2 to 
Jena 3.
http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html
Maybe this could be the main page for the migration, and link to other pages as 
the security/permissions module?
Bruno

 
  From: Claude Warren 
 To: dev@jena.apache.org 
 Sent: Sunday, July 19, 2015 7:45 PM
 Subject: JENA-955 and other documentation
   
There is an issue opened by Bruno (JENA-955) that is for updating the Jena
Security documentation to Jena Permissions.

I think given the breadth of the changes that are in place between 2.x and
3.0 we should have a page of migration/upgrade instructions, possibly with
sub pages for any components (like permissions) that have more complex
changes.

I think this is a story or an epic and should be created and executed
before the release of 3.0

I think that we will need to branch the documentation in SVN to perform
these changes as we don't want to affect the production site and any
potential contributions there.

Thoughts?
Claude

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


   
 

Re: JENA-955 and other documentation

[Bruno P. Kinoshita]

Hi Claude, 

I looked at the permissions/security module as I had some spare time and had 
never used it in a production server. But probably other parts of the docs will 
need to be updated as well.

>I think given the breadth of the changes that are in place between 2.x and
3.0 we should have a page of migration/upgrade instructions, possibly with
sub pages for any components (like permissions) that have more complex
changes.
+1 for migration/upgrade instructions somewhere like site or Wiki. This week 
I'll start using Jena at work, so I can test any documentation created for 
upgrading a Jena 2 server to Jena 3.

>I think this is a story or an epic and should be created and executed
before the release of 3.0

+1 and willing to help with the documentation and testing of the documentation.

>I think that we will need to branch the documentation in SVN to perform
these changes as we don't want to affect the production site and any
potential contributions there.
Are the changes in the SVN published to the live site? I thought they were 
published only to jena.staging.apache.org, and promoted to jena.apache.org 
after someone released a new version.
CheersBruno
 
  From: Claude Warren 
 To: dev@jena.apache.org 
 Sent: Sunday, July 19, 2015 7:45 PM
 Subject: JENA-955 and other documentation
   
There is an issue opened by Bruno (JENA-955) that is for updating the Jena
Security documentation to Jena Permissions.

I think given the breadth of the changes that are in place between 2.x and
3.0 we should have a page of migration/upgrade instructions, possibly with
sub pages for any components (like permissions) that have more complex
changes.

I think this is a story or an epic and should be created and executed
before the release of 3.0

I think that we will need to branch the documentation in SVN to perform
these changes as we don't want to affect the production site and any
potential contributions there.

Thoughts?
Claude

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


   
 

[jira] [Commented] (JENA-990) rename the UpdateDeniedException

[Claude Warren (JIRA)]

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

Claude Warren commented on JENA-990:


I originally placed the permissions specific exceptions: ReadDeniedException 
and UpdateDeniedExceptions within the permissions package.  However, If Fuseki 
is going to respond to them distinctly it will need to catch them.  To do this 
without importing all of the permissions package means they should probably be 
in the jena.shared package.  Any objections to moving them there?

I have rethought the AuthenticationRequiredException and think that it should 
be a child of OperationDeniedException instead.

>  rename the UpdateDeniedException
> -
>
> Key: JENA-990
> URL: https://issues.apache.org/jira/browse/JENA-990
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: Jena 3.0.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> As noted in a discussion on the dev list between myself and Andy this update 
> is to rename the current UpdateDeniedException to AccessDeniedException and 
> extend it from a newly created OperationDeniedException.
> AddDeniedException and DeleteDeniedException will extend 
> AccessDeniedException.
> jena-permissions will extend AccessDeniedException to create:
> ReadDeniedException -- for read restrictions
> UpdateDeniedException -- for update restrictions (modifying triples that 
> already exists as opposed to adding new triples)
> This will allow Fuskei to properly respond to the case where jena-permissions 
> is in place and there are update restrictions in place.  Currently Fuseki 
> returns this as a 500 error.  Once we have a common permission denied 
> exception we can return either authentication required or access denied as 
> appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

JENA-955 and other documentation

[Claude Warren]

There is an issue opened by Bruno (JENA-955) that is for updating the Jena
Security documentation to Jena Permissions.

I think given the breadth of the changes that are in place between 2.x and
3.0 we should have a page of migration/upgrade instructions, possibly with
sub pages for any components (like permissions) that have more complex
changes.

I think this is a story or an epic and should be created and executed
before the release of 3.0

I think that we will need to branch the documentation in SVN to perform
these changes as we don't want to affect the production site and any
potential contributions there.

Thoughts?
Claude

-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren