You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Fabian Christ <ch...@googlemail.com> on 2012/05/11 14:20:35 UTC
Status of STANBOL-553 soon ready for commit
Hi,
I am currently working on
https://issues.apache.org/jira/browse/STANBOL-553
which is about fixing the dependency management. During this work I
have touched literally each POM of Apache Stanbol. I will finish my
work soon and would be ready to commit my local changes. But before I
do this, I would like to know if I should wait and hold back this
commit because someone else may be working locally on some things that
get broken with my commit. So to prevent the pain of conflicts please
raise a hand if you have any local changes to the codebase that you
would like to commit before all POMs get changed.
Best,
- Fabian
--
Fabian
http://twitter.com/fctwitt
Re: CORS in Apache Stanbol
Posted by Sebastian Germesin <se...@dfki.de>.
see:
https://issues.apache.org/jira/browse/STANBOL-616
I am actually not sure whether this is also true for other components of Stanbol...
best regards,
Sebastian
On 16.05.2012, at 09:54, Rupert Westenthaler wrote:
>
> On 16.05.2012, at 09:50, Sebastian Germesin wrote:
>
>> Sure, can you send me the link to that?
>>
>
> https://issues.apache.org/jira/browse/STANBOL
>
>> On 16.05.2012, at 09:49, Rupert Westenthaler wrote:
>>
>>> Hi Sebastian, Melanie
>>>
>>> Looks like a Bug. Can you please create a JIRA issue for that
>>>
>>> best
>>> Rupert
>>>
>>> On 16.05.2012, at 09:41, Sebastian Germesin wrote:
>>>
>>>> Hi,
>>>>
>>>> I just had a look at the CORS support in Stanbol and I have a question to that.
>>>>
>>>> In the CORS specification [1], I read that in a CORS request with a preflight the client sets the request header:
>>>>
>>>> Access-Control-Request-Headers: .... (let's say: origin, content-type, accept)
>>>> Access-Control-Request-Method: .... (let's say: POST)
>>>>
>>>> and the server (in this case Stanbol) answers with:
>>>>
>>>> Access-Control-Allow-Headers: ... (let's say: origin, content-type, accept)
>>>> Access-Control-Allow-Origin: ... (let's say: *)
>>>> Access-Control-Allow-Method: (let's say: GET, POST, OPTIONS)
>>>>
>>>> However, when I perform a query to the Entityhub, e.g., http://dev.iks-project.eu:8081/entityhub/entity/
>>>> Stanbol answers correctly with
>>>>
>>>> Access-Control-Allow-Headers: origin, content-type, accept
>>>> Access-Control-Allow-Origin: *
>>>>
>>>> BUT:
>>>>
>>>> Access-Control-Request-Method: GET, POST, OPTIONS
>>>>
>>>> instead of
>>>>
>>>> Access-Control-Allow-Method: GET, POST, OPTIONS
>>>>
>>>> Gladly, for the GET and POST requests that somehow works anyways, but for a PUT and DELETE request
>>>> that fails again.
>>>>
>>>> Is that something that needs change in the CORS-implementation in Stanbol?
>>>>
>>>> Best regards,
>>>>
>>>> Sebastian
>>>>
>>>>
>>>>
>>>> [1] http://www.w3.org/TR/cors/
>>>
>>
>> --
>> M.Sc. Sebastian Germesin
>>
>> DFKI GmbH
>> Campus D3 2
>> Stuhlsatzenhausweg 3
>> D-66123 Saarbruecken, Germany
>>
>> phone: +49 (681) 85775 - 5079
>> fax: +49 (681) 85775 - 5021
>> mail: sebastian.germesin@dfki.de
>> http: www.dfki.de/~germesin
>> skype: neogermi1337
>> twitter: germesin
>>
>> --
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (DFKI) GmbH
>> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern; Amtsgericht Kaiserslautern, HRB 2313
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>>
>
--
M.Sc. Sebastian Germesin
DFKI GmbH
Campus D3 2
Stuhlsatzenhausweg 3
D-66123 Saarbruecken, Germany
phone: +49 (681) 85775 - 5079
fax: +49 (681) 85775 - 5021
mail: sebastian.germesin@dfki.de
http: www.dfki.de/~germesin
skype: neogermi1337
twitter: germesin
--
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (DFKI) GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern; Amtsgericht Kaiserslautern, HRB 2313
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Re: CORS in Apache Stanbol
Posted by Rupert Westenthaler <ru...@gmail.com>.
On 16.05.2012, at 09:50, Sebastian Germesin wrote:
> Sure, can you send me the link to that?
>
https://issues.apache.org/jira/browse/STANBOL
> On 16.05.2012, at 09:49, Rupert Westenthaler wrote:
>
>> Hi Sebastian, Melanie
>>
>> Looks like a Bug. Can you please create a JIRA issue for that
>>
>> best
>> Rupert
>>
>> On 16.05.2012, at 09:41, Sebastian Germesin wrote:
>>
>>> Hi,
>>>
>>> I just had a look at the CORS support in Stanbol and I have a question to that.
>>>
>>> In the CORS specification [1], I read that in a CORS request with a preflight the client sets the request header:
>>>
>>> Access-Control-Request-Headers: .... (let's say: origin, content-type, accept)
>>> Access-Control-Request-Method: .... (let's say: POST)
>>>
>>> and the server (in this case Stanbol) answers with:
>>>
>>> Access-Control-Allow-Headers: ... (let's say: origin, content-type, accept)
>>> Access-Control-Allow-Origin: ... (let's say: *)
>>> Access-Control-Allow-Method: (let's say: GET, POST, OPTIONS)
>>>
>>> However, when I perform a query to the Entityhub, e.g., http://dev.iks-project.eu:8081/entityhub/entity/
>>> Stanbol answers correctly with
>>>
>>> Access-Control-Allow-Headers: origin, content-type, accept
>>> Access-Control-Allow-Origin: *
>>>
>>> BUT:
>>>
>>> Access-Control-Request-Method: GET, POST, OPTIONS
>>>
>>> instead of
>>>
>>> Access-Control-Allow-Method: GET, POST, OPTIONS
>>>
>>> Gladly, for the GET and POST requests that somehow works anyways, but for a PUT and DELETE request
>>> that fails again.
>>>
>>> Is that something that needs change in the CORS-implementation in Stanbol?
>>>
>>> Best regards,
>>>
>>> Sebastian
>>>
>>>
>>>
>>> [1] http://www.w3.org/TR/cors/
>>
>
> --
> M.Sc. Sebastian Germesin
>
> DFKI GmbH
> Campus D3 2
> Stuhlsatzenhausweg 3
> D-66123 Saarbruecken, Germany
>
> phone: +49 (681) 85775 - 5079
> fax: +49 (681) 85775 - 5021
> mail: sebastian.germesin@dfki.de
> http: www.dfki.de/~germesin
> skype: neogermi1337
> twitter: germesin
>
> --
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (DFKI) GmbH
> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern; Amtsgericht Kaiserslautern, HRB 2313
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>
Re: CORS in Apache Stanbol
Posted by Sebastian Germesin <se...@dfki.de>.
Sure, can you send me the link to that?
On 16.05.2012, at 09:49, Rupert Westenthaler wrote:
> Hi Sebastian, Melanie
>
> Looks like a Bug. Can you please create a JIRA issue for that
>
> best
> Rupert
>
> On 16.05.2012, at 09:41, Sebastian Germesin wrote:
>
>> Hi,
>>
>> I just had a look at the CORS support in Stanbol and I have a question to that.
>>
>> In the CORS specification [1], I read that in a CORS request with a preflight the client sets the request header:
>>
>> Access-Control-Request-Headers: .... (let's say: origin, content-type, accept)
>> Access-Control-Request-Method: .... (let's say: POST)
>>
>> and the server (in this case Stanbol) answers with:
>>
>> Access-Control-Allow-Headers: ... (let's say: origin, content-type, accept)
>> Access-Control-Allow-Origin: ... (let's say: *)
>> Access-Control-Allow-Method: (let's say: GET, POST, OPTIONS)
>>
>> However, when I perform a query to the Entityhub, e.g., http://dev.iks-project.eu:8081/entityhub/entity/
>> Stanbol answers correctly with
>>
>> Access-Control-Allow-Headers: origin, content-type, accept
>> Access-Control-Allow-Origin: *
>>
>> BUT:
>>
>> Access-Control-Request-Method: GET, POST, OPTIONS
>>
>> instead of
>>
>> Access-Control-Allow-Method: GET, POST, OPTIONS
>>
>> Gladly, for the GET and POST requests that somehow works anyways, but for a PUT and DELETE request
>> that fails again.
>>
>> Is that something that needs change in the CORS-implementation in Stanbol?
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>>
>> [1] http://www.w3.org/TR/cors/
>
--
M.Sc. Sebastian Germesin
DFKI GmbH
Campus D3 2
Stuhlsatzenhausweg 3
D-66123 Saarbruecken, Germany
phone: +49 (681) 85775 - 5079
fax: +49 (681) 85775 - 5021
mail: sebastian.germesin@dfki.de
http: www.dfki.de/~germesin
skype: neogermi1337
twitter: germesin
--
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (DFKI) GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern; Amtsgericht Kaiserslautern, HRB 2313
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender), Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Re: CORS in Apache Stanbol
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Sebastian, Melanie
Looks like a Bug. Can you please create a JIRA issue for that
best
Rupert
On 16.05.2012, at 09:41, Sebastian Germesin wrote:
> Hi,
>
> I just had a look at the CORS support in Stanbol and I have a question to that.
>
> In the CORS specification [1], I read that in a CORS request with a preflight the client sets the request header:
>
> Access-Control-Request-Headers: .... (let's say: origin, content-type, accept)
> Access-Control-Request-Method: .... (let's say: POST)
>
> and the server (in this case Stanbol) answers with:
>
> Access-Control-Allow-Headers: ... (let's say: origin, content-type, accept)
> Access-Control-Allow-Origin: ... (let's say: *)
> Access-Control-Allow-Method: (let's say: GET, POST, OPTIONS)
>
> However, when I perform a query to the Entityhub, e.g., http://dev.iks-project.eu:8081/entityhub/entity/
> Stanbol answers correctly with
>
> Access-Control-Allow-Headers: origin, content-type, accept
> Access-Control-Allow-Origin: *
>
> BUT:
>
> Access-Control-Request-Method: GET, POST, OPTIONS
>
> instead of
>
> Access-Control-Allow-Method: GET, POST, OPTIONS
>
> Gladly, for the GET and POST requests that somehow works anyways, but for a PUT and DELETE request
> that fails again.
>
> Is that something that needs change in the CORS-implementation in Stanbol?
>
> Best regards,
>
> Sebastian
>
>
>
> [1] http://www.w3.org/TR/cors/
CORS in Apache Stanbol
Posted by Sebastian Germesin <se...@dfki.de>.
Hi,
I just had a look at the CORS support in Stanbol and I have a question to that.
In the CORS specification [1], I read that in a CORS request with a preflight the client sets the request header:
Access-Control-Request-Headers: .... (let's say: origin, content-type, accept)
Access-Control-Request-Method: .... (let's say: POST)
and the server (in this case Stanbol) answers with:
Access-Control-Allow-Headers: ... (let's say: origin, content-type, accept)
Access-Control-Allow-Origin: ... (let's say: *)
Access-Control-Allow-Method: (let's say: GET, POST, OPTIONS)
However, when I perform a query to the Entityhub, e.g., http://dev.iks-project.eu:8081/entityhub/entity/
Stanbol answers correctly with
Access-Control-Allow-Headers: origin, content-type, accept
Access-Control-Allow-Origin: *
BUT:
Access-Control-Request-Method: GET, POST, OPTIONS
instead of
Access-Control-Allow-Method: GET, POST, OPTIONS
Gladly, for the GET and POST requests that somehow works anyways, but for a PUT and DELETE request
that fails again.
Is that something that needs change in the CORS-implementation in Stanbol?
Best regards,
Sebastian
[1] http://www.w3.org/TR/cors/
Re: Status of STANBOL-553 soon ready for commit
Posted by Fabian Christ <ch...@googlemail.com>.
Hi Rupert,
thanks for the info. I am doing final checks now and do the commit.
Best,
- Fabian
2012/5/11 Rupert Westenthaler <ru...@gmail.com>:
> Hi,
>
> I committed all bigger local changes today.
>
> You might be interested that from this commit on
>
> o.a.s.entityhub.yard.solr
>
> now depends on the 0.10 of
>
> o.a.s.commons.solr.core
>
> and
>
> o.a.s.entityhub.jersey
>
> on 0.10 of
>
> o.a.s.commons.web.base
>
> best
> Rupert
>
> On Fri, May 11, 2012 at 2:20 PM, Fabian Christ
> <ch...@googlemail.com> wrote:
>> Hi,
>>
>> I am currently working on
>>
>> https://issues.apache.org/jira/browse/STANBOL-553
>>
>> which is about fixing the dependency management. During this work I
>> have touched literally each POM of Apache Stanbol. I will finish my
>> work soon and would be ready to commit my local changes. But before I
>> do this, I would like to know if I should wait and hold back this
>> commit because someone else may be working locally on some things that
>> get broken with my commit. So to prevent the pain of conflicts please
>> raise a hand if you have any local changes to the codebase that you
>> would like to commit before all POMs get changed.
>>
>> Best,
>> - Fabian
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
Fabian
http://twitter.com/fctwitt
Re: Status of STANBOL-553 soon ready for commit
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi,
I committed all bigger local changes today.
You might be interested that from this commit on
o.a.s.entityhub.yard.solr
now depends on the 0.10 of
o.a.s.commons.solr.core
and
o.a.s.entityhub.jersey
on 0.10 of
o.a.s.commons.web.base
best
Rupert
On Fri, May 11, 2012 at 2:20 PM, Fabian Christ
<ch...@googlemail.com> wrote:
> Hi,
>
> I am currently working on
>
> https://issues.apache.org/jira/browse/STANBOL-553
>
> which is about fixing the dependency management. During this work I
> have touched literally each POM of Apache Stanbol. I will finish my
> work soon and would be ready to commit my local changes. But before I
> do this, I would like to know if I should wait and hold back this
> commit because someone else may be working locally on some things that
> get broken with my commit. So to prevent the pain of conflicts please
> raise a hand if you have any local changes to the codebase that you
> would like to commit before all POMs get changed.
>
> Best,
> - Fabian
>
> --
> Fabian
> http://twitter.com/fctwitt
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen