[JBoss JIRA] (SRAMP-129) Be more selective about what errors get logged by the server
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-129?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on SRAMP-129:
-------------------------------------
(09:39:14 AM) eric.wittmann(a)gmail.com/0DCF6CCB: So it's just a question of which exceptions get logged and which don't?
(09:39:52 AM) eric.wittmann(a)gmail.com/0DCF6CCB: If so, doesn't that come down to a case-by-case judgement call?
(09:40:03 AM) Kurt Stam: y - server errors should get logged on the server, user/client errors are 'normal' processing for the server and should not get logged on the server
(09:40:22 AM) Kurt Stam: yes it is a judgement call, which only you and I can make
(09:40:27 AM) eric.wittmann(a)gmail.com/0DCF6CCB: lol
(09:40:33 AM) Kurt Stam: (not the administrator of the server)
(09:40:36 AM) eric.wittmann(a)gmail.com/0DCF6CCB: sure
(09:40:43 AM) Kurt Stam: so we need to filter out what we log
(09:40:50 AM) Kurt Stam: so he can do his job
(09:41:33 AM) eric.wittmann(a)gmail.com/0DCF6CCB: so it sounds like we need an Exception hierarchy - so we can determine which ones are hard server errors and which ones are "user" errors (invalid query syntax, uuid not found, etc)
(09:41:34 AM) eric.wittmann(a)gmail.com/0DCF6CCB: yes?
(09:41:47 AM) Kurt Stam: yes
(09:41:49 AM) Kurt Stam: we do
(09:41:54 AM) eric.wittmann(a)gmail.com/0DCF6CCB: ok
> Be more selective about what errors get logged by the server
> ------------------------------------------------------------
>
> Key: SRAMP-129
> URL: https://issues.jboss.org/browse/SRAMP-129
> Project: S-RAMP
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Eric Wittmann
> Fix For: Milestone 3 (Workflow and Relationships)
>
>
> There are a few stacktraces when running the test. We should change our code to make sure we don't show stack traces if there is no true exception.
> In general, this means we should be able to tell the difference between a hard server error (ioexception, modeshape blew up exception, etc) and a "user" error (invalid s-ramp query syntax, uuid not found, etc).
--
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
12 years
[JBoss JIRA] (SRAMP-129) Be more selective about what errors get logged by the server
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-129?page=com.atlassian.jira.plugin.... ]
Eric Wittmann updated SRAMP-129:
--------------------------------
Description:
There are a few stacktraces when running the test. We should change our code to make sure we don't show stack traces if there is no true exception.
In general, this means we should be able to tell the difference between a hard server error (ioexception, modeshape blew up exception, etc) and a "user" error (invalid s-ramp query syntax, uuid not found, etc).
was:There are a few stacktraces when running the test. We should change our code to make sure we don't show stack traces if there is no true exception.
> Be more selective about what errors get logged by the server
> ------------------------------------------------------------
>
> Key: SRAMP-129
> URL: https://issues.jboss.org/browse/SRAMP-129
> Project: S-RAMP
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Eric Wittmann
> Fix For: Milestone 3 (Workflow and Relationships)
>
>
> There are a few stacktraces when running the test. We should change our code to make sure we don't show stack traces if there is no true exception.
> In general, this means we should be able to tell the difference between a hard server error (ioexception, modeshape blew up exception, etc) and a "user" error (invalid s-ramp query syntax, uuid not found, etc).
--
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
12 years
[JBoss JIRA] (SRAMP-124) stacktrace in the log when not found uuid
by Kurt Stam (JIRA)
[ https://issues.jboss.org/browse/SRAMP-124?page=com.atlassian.jira.plugin.... ]
Kurt Stam reassigned SRAMP-124:
-------------------------------
Assignee: Eric Wittmann (was: Kurt Stam)
> stacktrace in the log when not found uuid
> -----------------------------------------
>
> Key: SRAMP-124
> URL: https://issues.jboss.org/browse/SRAMP-124
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Persistence
> Reporter: Kurt Stam
> Assignee: Eric Wittmann
> Fix For: Milestone 3 (Workflow and Relationships)
>
>
> When a uuid is not found we should not log an exception, but rather a message at the INFO level
> 09:31:25,971 ERROR Error found updating artifact meta-data: 2e455ad3-a469-401b-abe1-d3e737192893
> java.lang.Exception: Relationship creation error - failed to find an s-ramp artifact with target UUID: not-a-valid-uuid
> at org.overlord.sramp.repository.jcr.JCRPersistence$JCRReferenceFactoryImpl.createReference(JCRPersistence.java:766)
> at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.setRelationships(ArtifactToJCRNodeVisitor.java:536)
--
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
12 years
[JBoss JIRA] (SRAMP-67) Add HTTP basic authentication
by Kurt Stam (JIRA)
[ https://issues.jboss.org/browse/SRAMP-67?page=com.atlassian.jira.plugin.s... ]
Kurt Stam commented on SRAMP-67:
--------------------------------
We are investigation PicketLink for SSO. Let's do it the right way and wait with this till we know what that is.
> Add HTTP basic authentication
> -----------------------------
>
> Key: SRAMP-67
> URL: https://issues.jboss.org/browse/SRAMP-67
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Kurt Stam
> Fix For: Milestone 4
>
>
> The S-RAMP Specification does not attempt to define a security model for products which implement it. For the Atom Binding, the only security requirement is that at a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication in conjunction with a connection made with TLS.
--
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
12 years
[JBoss JIRA] (SRAMP-67) Add HTTP basic authentication
by Kurt Stam (JIRA)
[ https://issues.jboss.org/browse/SRAMP-67?page=com.atlassian.jira.plugin.s... ]
Kurt Stam updated SRAMP-67:
---------------------------
Fix Version/s: Milestone 4
(was: Milestone 3 (Workflow and Relationships))
> Add HTTP basic authentication
> -----------------------------
>
> Key: SRAMP-67
> URL: https://issues.jboss.org/browse/SRAMP-67
> Project: S-RAMP
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kurt Stam
> Assignee: Kurt Stam
> Fix For: Milestone 4
>
>
> The S-RAMP Specification does not attempt to define a security model for products which implement it. For the Atom Binding, the only security requirement is that at a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication in conjunction with a connection made with TLS.
--
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
12 years