Hi,
normally I don't go in these technical discussions, since I'm a mere
user of Stanbol. But, because of this, I think this time I could
contribute with another point of view to the poll.
Stanbol is a a set of RESTful components for semantic content
management. Therefore, using it I'd expect whatever security it could be
provided, should be something optional on top of those components; i.e.,
enabling security should not affect the behaviour.
I don't have much details how this aspect is being implemented. But
what's clear is it does affect the behaviour of the components, and how
other people are using Stanbol
Therefore, I vote +1 to what Bertrand proposed, until the design of such
security mechanism is agreed and can be guaranteed would not affect the
internal behaviour, which in the end in the purpose of the project.
Cheers,
On 05/04/13 13:51, Rupert Westenthaler wrote:
Hi all,
My viewpoint is as follows:
* Disabling Security as default: Stanbol is still not functioning to
100% if the Security-Manager is enabled hence IMHO deactivating this
feature is the logical consequence.
* Enabling Security for IntegrationTests - because when you change
things, than it is good to validate if it runs if an SecurityManager
is present. Sometimes small changes do break security stuff (e.g. if a
library that loads stuff via context classloader is imported from a
different bundle the SecurityManager might say NO) ... meaning that
even configuration changes might break code ... so having those things
tested is important (unless we decide to not support SecurityManager
stuff at all - like it is done my Solr, Tika ... but this was part of
[1] and I accept the decision)
To ensure that Stanbol is 100% working with the Security-Manager
enabled is not only the question of fixing all those components. It
will also require to test all those components during the
integration-tests and as all those components depend on some external
services this is not an easy thing to achieve. Because (1) this would
also mean that failures of remote services would fail the
integration-tests and (2) it will no longer allow to complete the
integration-tests while offline.
On the other side having not all component tested with active
SecurityManager would make it very possible that some minor change
(such as a version upgrade of a dependency) could break an component
without noticed by the Developer nor the Jenkins build.
To Summarize: As long as there are no solutions for those things I
would really like to have security deactivated by default. This means
that users that are not bordered with it will not run into problems
they would not need to boarder with. Users that do need (use) the
security features will run into those problems. Those users will also
more likely understand those issues and report/patch them.
WDYT
Rupert
p.s.
On Fri, Apr 5, 2013 at 9:59 AM, Adrian Gschwend<ml-...@netlabs.org> wrote:
WTF
I hope the this stand for "Want To Fix" otherwise I would recommend to
think twice before hitting the send button if the receiver includes a
public mailing list ...
--
| Rupert Westenthaler rupert.westentha...@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
