You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Danny Ayers <da...@gmail.com> on 2013/02/13 11:45:45 UTC
breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
The root of the problem making User Management totally unusable is the
latest change made at:
http://svn.apache.org/viewvc/stanbol/trunk/commons/security/usermanagement/src/main/java/org/apache/stanbol/commons/usermanagement/WebConsolePlugin.java?view=log
associated with:
STANBOL-910
Refactor Viewable and LDpath Freemaker Template rendering
(The previous version used a LdRenderer, the latest uses a LdViewableWriter)
Would it please be possible to revert this change (or refactor to a
working state).
Thanks,
Danny.
On 13 February 2013 11:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Clearly something seems quite weird of using the MessageBodyWriter
> which should be a service for JAX-RS in this non JAX-RS context. The
> Original Version was directly accessing LdRenderer.
>
> You should see when this changed and maybe reopen the issue the change
> was associated with.
>
> Cheers,
> Reto
>
> On Wed, Feb 13, 2013 at 11:16 AM, Danny Ayers <da...@gmail.com> wrote:
>> will do.
>>
>> On 13 February 2013 11:12, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>> Hi
>>>
>>> I see the problem too.
>>>
>>> Can you create an issue to address this?
>>>
>>> Cheers,
>>> Reto
>>>
>>> On Tue, Feb 12, 2013 at 3:54 PM, Danny Ayers <da...@gmail.com> wrote:
>>>> [I'll post again later re. User Management module more generally, re.
>>>> STANBOL-897, but before going any further I could do with a working
>>>> system :) ]
>>>>
>>>> From a checkout & install from svn, I believe a pristine system, when
>>>> I click on the User Management tab I'm getting a 500:
>>>>
>>>> java.lang.IllegalStateException: WRITER
>>>> at org.mortbay.jetty.Response.getOutputStream(Response.java:594)
>>>> at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:112)
>>>> at org.apache.stanbol.commons.usermanagement.WebConsolePlugin.renderContent(WebConsolePlugin.java:79)
>>>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:155)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>>> ...
>>>>
>>>> When I was working from a git clone of a git clone of the svn (!) this
>>>> wasn't happening, but I haven't been able to track down what's
>>>> changed.
>>>>
>>>> Possibly related is this message on startup:
>>>>
>>>> WARNING: A HTTP GET method, public void
>>>> org.apache.clerezza.platform.security.permissioncheck.PermissionCheck.checkPermission(java.lang.String),
>>>> MUST return a non-void type.
>>>>
>>>> The call which leads to the 500 is:
>>>>
>>>> private LdViewableWriter rdfViewableWriter;
>>>>
>>>> ...
>>>>
>>>> RdfViewable rdfViewable = new RdfViewable(
>>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>>> userManager.getUserType());
>>>>
>>>> rdfViewableWriter.writeTo(rdfViewable, RdfViewable.class,
>>>> RdfViewable.class,
>>>> RdfViewable.class.getAnnotations(), MediaType.TEXT_HTML_TYPE,
>>>> null, response.getOutputStream());
>>>>
>>>> I've tried a dummy .ftl - that didn't change anything, and
>>>> userManager.getUserType() is producing an appropriate value (a
>>>> foaf:Agent).
>>>>
>>>> I vaguely remember this kind of exception arising when you try
>>>> writing to a closed stream. But there's so much filter chaining going
>>>> on, and not a little magic, it's really hard to see what's going
>>>> wrong.
>>>>
>>>> Any suggestions?
>>>>
>>>> Cheers,
>>>> Danny.
>>>>
>>>> --
>>>> http://dannyayers.com
>>>>
>>>> http://webbeep.it - text to tones and back again
>>
>>
>>
>> --
>> http://dannyayers.com
>>
>> http://webbeep.it - text to tones and back again
--
http://dannyayers.com
http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Danny Ayers <da...@gmail.com>.
On 13 February 2013 14:22, Rupert Westenthaler
<ru...@gmail.com> wrote:
Hi Rupert,
I can't really comment on the LdRenderer issue, not familiar with the
internals - except to reiterate that a quick fix (such as a revert)
would be appreciated.
but re.
>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
My mistake there I think, must have conflicting resources - a similar
call (which isn't going through the RdfViewable bits) is still working
fine:
curl --user admin:admin -H "Accept:text/turtle"
http://localhost:8080/user-management/roles/anonymous
(produces a bunch of turtle)
Cheers,
Danny.
--
http://dannyayers.com
http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User Management/LdViewableWriter
IllegalStateException)
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi Reto,
On 18/02/13 11:56, Reto Bachmann-Gmür wrote:
> On Mon, Feb 18, 2013 at 6:37 AM, Rupert Westenthaler
> rupert.westenthaler@gmail.com> wrote:
>> I plan to work on the upgrade
>> to the newest LDpath version as soon as the first version with the
>> org.apache.marmotta.ldpath packages is released.
>
> Neither on http://incubator.apache.org/marmotta which doesn't exist nor on
> http://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201302.mbox/browserI
> find any reference to the package your preparing for its release. So
> I'm afraid this might have more to do with a Salzburg research agenda than with
> the community process.
Actually a quite community-driven process, but maybe Markmail helps you
better on find clues about it:
http://markmail.org/search/?q=list%3Aorg.apache.marmotta.dev+ldpath
Sorry, but first incubating release will require us a few weeks more.
Anyway, whatever we can help or support Stanbol, please do not hesitate
to contact us.
Best,
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Re: breakage from Refactor Viewable and LDpath (was Re: User Management/LdViewableWriter IllegalStateException)
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Hi Reto,
just replying to the issue that directly affects me...
Am 18.02.2013 um 11:56 schrieb Reto Bachmann-Gmür:
>
>> I plan to work on the upgrade
>> to the newest LDpath version as soon as the first version with the
>> org.apache.marmotta.ldpath packages is released. This was also the
>> reason why I tried to remove all other functionality out of this
>> bundle. Now with the new LdRenderer this will be no longer possible -
>> but maybe thats ok as I do not see an other module where the
>> LdRenderer fits well.
>>
>
> Neither on http://incubator.apache.org/marmotta which doesn't exist
The correct address is http://marmotta.incubator.apache.org (according to the changed way of handling incubation projects). Which also does not exist yet, because INFRA is currently busy with preparing ApacheCon and with moving old projects to svnpubsub (see https://issues.apache.org/jira/browse/INFRA-5624). Not our fault, the issue is open since december. In the meantime, you can go to the wiki at http://wiki.apache.org/marmotta/. We are in the process of moving the documentation over there, including LDPath.
> nor on
> http://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201302.mbox/browserI
> find any reference to the package your preparing for its release. So
> I'm
> afraid this might have more to do with a Salzburg research agenda than with
> the community process.
LDPath is currently a subproject of the LMF and will be a subproject of Marmotta. Version 2.6 has been released last Friday together with the rest of the LMF, as a preparation of the code importation into the Apache GIT repository. The layout of the code importation was discussed in http://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201301.mbox/%3C50E58387.7070500%40apache.org%3E , where even LDPath is mentioned.
Code importation (including LDPath) is scheduled to be completed end of February (https://issues.apache.org/jira/browse/MARMOTTA-2) as "Apache Marmotta 3.0 (incubating)". Obviously, the packages will be renamed accordingly then. I suppose Rupert was referring to this (quite obvious) renaming.
This is BTW not a Salzburg Research agenda. Marmotta will provide a number of generic Linked Data libraries (including LDPath, LDClient, LDCache and the KiWi triple store backend) that can be used independently of Marmotta. We have daily scrum meetings in IRC where such issues are discussed (see http://wilderness.apache.org/archives/). Of course we usually do not discuss obvious renamings of individual packages there (so a search for the new package name will not give you any results).
Greetings.
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Mon, Feb 18, 2013 at 6:37 AM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> On Thu, Feb 14, 2013 at 2:43 PM, Reto Bachmann-Gmür <re...@apache.org>
> wrote:
> > Hi,
> >
> > I did some re-refactoring yesterday to me there's one open point with
> > STANBOL-910 which I described in the latest comment. If I don't get any
> > feedback I'll go for the suggested approach of merging the two
> > viewable-writer modules but I can live perfectly well we the other
> > described approach (separate rdfviewable-writer module).
> >
>
> I am -1 for making the Stanbol UI depending on LDpath. Simple because
> I do not see a good reason why one would need such an dependency.
>
As I said I can live with the variant where the RDF Writer is separater
from the legacy Vieawable.
But for your dependency reduction argument I would like to point to your
attention that with the version previous to my refactoring every stanbol
component was depending on freemarker. This was the independently on wheter
it would use this capabilities or not. Now a module depends only on the
rendering mechanism it actually needs. Also note that ldpathtemplate is
very small, especially considering that we use ldpath anyway.
>
> I also think that commons.ldpathtemplate should be removed as soon as
> we switch to a newer LDpath version for that the ldpathtemplate code
> is available as bundle in maven central.
No. like commons.freemarker this is not supposed to mainly be a bundle
providing ldpathtemplate as a bundle. It only does so because no usable
bundle was available. Its main purpose it provide a service for simple
access to this rendering avoiding code duplication.
> I plan to work on the upgrade
> to the newest LDpath version as soon as the first version with the
> org.apache.marmotta.ldpath packages is released. This was also the
> reason why I tried to remove all other functionality out of this
> bundle. Now with the new LdRenderer this will be no longer possible -
> but maybe thats ok as I do not see an other module where the
> LdRenderer fits well.
>
Neither on http://incubator.apache.org/marmotta which doesn't exist nor on
http://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201302.mbox/browserI
find any reference to the package your preparing for its release. So
I'm
afraid this might have more to do with a Salzburg research agenda than with
the community process.
>
> Having an own commons/freemaker module is IMO a good ides, as it
> solves the issue that commons.web.core embeds and exports freemaker.
> It can also be handy if we want to seperate the WebUI from the RESTful
> services at a later point in time.
>
Tha's not to be postponed to a later point in time. I'm working on the
archetype which shows how RESTfull services can be build. Stanbol was
always about REST, yet we are not yet providing a single REST service. With
the RDF based frontend we get closer to this. As standard RDF formats and
well defined ontologies will satisfy the hypermedia requirement of REST.
The infrastructure is there, the task is remove the usage of Viewable and
use RDF to describe the service to its client (with RDFVieablw this RDF can
be converted to a human friendly representation if the respective bundles
are present).
Cheers,
Reto
>
> best
> Rupert
>
> > Cheers,
> > Reto
> >
> > On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ <
> christ.fabian@googlemail.com
> >> wrote:
> >
> >> Hi,
> >>
> >> I agree that we should avoid to work on many things in parallel. Try
> >> to implement and commit things step by step. Otherwise things are hard
> >> to follow and not easy to revert if discussion come up.
> >>
> >> To the situation at hand: I can not say anything on the technical
> >> level to the concrete problem. Are you now in the position Reto to
> >> work around the refactoring and make the usermanager work again for
> >> you? Once it runs again - we should find a consensus how things should
> >> be changed.
> >>
> >> Best,
> >> - Fabian
> >>
> >> 2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
> >> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
> >> > <ru...@gmail.com> wrote:
> >> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <
> reto@wymiwyg.com>
> >> wrote:
> >> >>>
> >> >>> Please just restore the original LdRenderer service an the
> >> >>> corresponding version of the UserManager. We can add an
> >> >>> RdfViewablRenderer service later, I think its overarchitecture to
> >> >>> separate out the LDVieable implementation. But first things first:
> >> >>> restore the better status quo ante with the Ldrenderer.
> >> >>
> >> >> LDRenderer was in ldpathtemplate; I created a new module, added those
> >> >> to bundlelists (both in trunk and a branch); changed exports and
> >> >> import statements that are now conflicting with an lot of additional
> >> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
> >> >> think reverting is no longer an option as it would take longer as
> >> >> implementing the service as suggested above.
> >> >
> >> > I think we should avoid working on an issue while dependent issues
> >> > aren't resolved.
> >> >
> >> > Also removing the LDRenderer service was not something which was clear
> >> > that this would happen neither from the description of the issue nor
> >> > from the discussion on the list.
> >> >
> >> > As you refuse to do it, I'll read the LdRenderer service (using your
> >> > new TemplateLoader service) so that UserManager can be reverted to
> >> > where the code was both more elegant and working.
> >> >
> >> > Reto
> >> >>
> >> >> best
> >> >> Rupert
> >> >>
> >> >> --
> >> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >> >> | Bodenlehenstraße 11 ++43-699-11108907
> >> >> | A-5500 Bischofshofen
> >>
> >>
> >>
> >> --
> >> Fabian
> >> http://twitter.com/fctwitt
> >>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Mon, Feb 18, 2013 at 6:58 AM, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> p.s maybe we should contribute the Clerezza LDpath integration to
> Clerezza instead of managing those modules in Stanbol. This would
> affect the modules
>
> * commons.ldpath.clerezza
> * commons.ldpathtemplate
>
> WDYT
>
These modules depend on freemarker which is not present in clerezza. I'd
suggest to see how things consolidate and how we manage to move to RDF/Rest
and get rid of the old tightly coupüled presentation layer before moving
around stuff.
Reto
> Rupert
>
> On Mon, Feb 18, 2013 at 6:37 AM, Rupert Westenthaler
> <ru...@gmail.com> wrote:
> > On Thu, Feb 14, 2013 at 2:43 PM, Reto Bachmann-Gmür <re...@apache.org>
> wrote:
> >> Hi,
> >>
> >> I did some re-refactoring yesterday to me there's one open point with
> >> STANBOL-910 which I described in the latest comment. If I don't get any
> >> feedback I'll go for the suggested approach of merging the two
> >> viewable-writer modules but I can live perfectly well we the other
> >> described approach (separate rdfviewable-writer module).
> >>
> >
> > I am -1 for making the Stanbol UI depending on LDpath. Simple because
> > I do not see a good reason why one would need such an dependency.
> >
> > I also think that commons.ldpathtemplate should be removed as soon as
> > we switch to a newer LDpath version for that the ldpathtemplate code
> > is available as bundle in maven central. I plan to work on the upgrade
> > to the newest LDpath version as soon as the first version with the
> > org.apache.marmotta.ldpath packages is released. This was also the
> > reason why I tried to remove all other functionality out of this
> > bundle. Now with the new LdRenderer this will be no longer possible -
> > but maybe thats ok as I do not see an other module where the
> > LdRenderer fits well.
> >
> > Having an own commons/freemaker module is IMO a good ides, as it
> > solves the issue that commons.web.core embeds and exports freemaker.
> > It can also be handy if we want to seperate the WebUI from the RESTful
> > services at a later point in time.
> >
> > best
> > Rupert
> >
> >> Cheers,
> >> Reto
> >>
> >> On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ <
> christ.fabian@googlemail.com
> >>> wrote:
> >>
> >>> Hi,
> >>>
> >>> I agree that we should avoid to work on many things in parallel. Try
> >>> to implement and commit things step by step. Otherwise things are hard
> >>> to follow and not easy to revert if discussion come up.
> >>>
> >>> To the situation at hand: I can not say anything on the technical
> >>> level to the concrete problem. Are you now in the position Reto to
> >>> work around the refactoring and make the usermanager work again for
> >>> you? Once it runs again - we should find a consensus how things should
> >>> be changed.
> >>>
> >>> Best,
> >>> - Fabian
> >>>
> >>> 2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
> >>> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
> >>> > <ru...@gmail.com> wrote:
> >>> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <
> reto@wymiwyg.com>
> >>> wrote:
> >>> >>>
> >>> >>> Please just restore the original LdRenderer service an the
> >>> >>> corresponding version of the UserManager. We can add an
> >>> >>> RdfViewablRenderer service later, I think its overarchitecture to
> >>> >>> separate out the LDVieable implementation. But first things first:
> >>> >>> restore the better status quo ante with the Ldrenderer.
> >>> >>
> >>> >> LDRenderer was in ldpathtemplate; I created a new module, added
> those
> >>> >> to bundlelists (both in trunk and a branch); changed exports and
> >>> >> import statements that are now conflicting with an lot of additional
> >>> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
> >>> >> think reverting is no longer an option as it would take longer as
> >>> >> implementing the service as suggested above.
> >>> >
> >>> > I think we should avoid working on an issue while dependent issues
> >>> > aren't resolved.
> >>> >
> >>> > Also removing the LDRenderer service was not something which was
> clear
> >>> > that this would happen neither from the description of the issue nor
> >>> > from the discussion on the list.
> >>> >
> >>> > As you refuse to do it, I'll read the LdRenderer service (using your
> >>> > new TemplateLoader service) so that UserManager can be reverted to
> >>> > where the code was both more elegant and working.
> >>> >
> >>> > Reto
> >>> >>
> >>> >> best
> >>> >> Rupert
> >>> >>
> >>> >> --
> >>> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >>> >> | Bodenlehenstraße 11 ++43-699-11108907
> >>> >> | A-5500 Bischofshofen
> >>>
> >>>
> >>>
> >>> --
> >>> Fabian
> >>> http://twitter.com/fctwitt
> >>>
> >
> >
> >
> > --
> > | Rupert Westenthaler rupert.westenthaler@gmail.com
> > | Bodenlehenstraße 11 ++43-699-11108907
> > | A-5500 Bischofshofen
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Rupert Westenthaler <ru...@gmail.com>.
p.s maybe we should contribute the Clerezza LDpath integration to
Clerezza instead of managing those modules in Stanbol. This would
affect the modules
* commons.ldpath.clerezza
* commons.ldpathtemplate
WDYT
Rupert
On Mon, Feb 18, 2013 at 6:37 AM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> On Thu, Feb 14, 2013 at 2:43 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> Hi,
>>
>> I did some re-refactoring yesterday to me there's one open point with
>> STANBOL-910 which I described in the latest comment. If I don't get any
>> feedback I'll go for the suggested approach of merging the two
>> viewable-writer modules but I can live perfectly well we the other
>> described approach (separate rdfviewable-writer module).
>>
>
> I am -1 for making the Stanbol UI depending on LDpath. Simple because
> I do not see a good reason why one would need such an dependency.
>
> I also think that commons.ldpathtemplate should be removed as soon as
> we switch to a newer LDpath version for that the ldpathtemplate code
> is available as bundle in maven central. I plan to work on the upgrade
> to the newest LDpath version as soon as the first version with the
> org.apache.marmotta.ldpath packages is released. This was also the
> reason why I tried to remove all other functionality out of this
> bundle. Now with the new LdRenderer this will be no longer possible -
> but maybe thats ok as I do not see an other module where the
> LdRenderer fits well.
>
> Having an own commons/freemaker module is IMO a good ides, as it
> solves the issue that commons.web.core embeds and exports freemaker.
> It can also be handy if we want to seperate the WebUI from the RESTful
> services at a later point in time.
>
> best
> Rupert
>
>> Cheers,
>> Reto
>>
>> On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ <christ.fabian@googlemail.com
>>> wrote:
>>
>>> Hi,
>>>
>>> I agree that we should avoid to work on many things in parallel. Try
>>> to implement and commit things step by step. Otherwise things are hard
>>> to follow and not easy to revert if discussion come up.
>>>
>>> To the situation at hand: I can not say anything on the technical
>>> level to the concrete problem. Are you now in the position Reto to
>>> work around the refactoring and make the usermanager work again for
>>> you? Once it runs again - we should find a consensus how things should
>>> be changed.
>>>
>>> Best,
>>> - Fabian
>>>
>>> 2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
>>> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
>>> > <ru...@gmail.com> wrote:
>>> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
>>> wrote:
>>> >>>
>>> >>> Please just restore the original LdRenderer service an the
>>> >>> corresponding version of the UserManager. We can add an
>>> >>> RdfViewablRenderer service later, I think its overarchitecture to
>>> >>> separate out the LDVieable implementation. But first things first:
>>> >>> restore the better status quo ante with the Ldrenderer.
>>> >>
>>> >> LDRenderer was in ldpathtemplate; I created a new module, added those
>>> >> to bundlelists (both in trunk and a branch); changed exports and
>>> >> import statements that are now conflicting with an lot of additional
>>> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
>>> >> think reverting is no longer an option as it would take longer as
>>> >> implementing the service as suggested above.
>>> >
>>> > I think we should avoid working on an issue while dependent issues
>>> > aren't resolved.
>>> >
>>> > Also removing the LDRenderer service was not something which was clear
>>> > that this would happen neither from the description of the issue nor
>>> > from the discussion on the list.
>>> >
>>> > As you refuse to do it, I'll read the LdRenderer service (using your
>>> > new TemplateLoader service) so that UserManager can be reverted to
>>> > where the code was both more elegant and working.
>>> >
>>> > Reto
>>> >>
>>> >> best
>>> >> Rupert
>>> >>
>>> >> --
>>> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> >> | Bodenlehenstraße 11 ++43-699-11108907
>>> >> | A-5500 Bischofshofen
>>>
>>>
>>>
>>> --
>>> Fabian
>>> http://twitter.com/fctwitt
>>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Thu, Feb 14, 2013 at 2:43 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi,
>
> I did some re-refactoring yesterday to me there's one open point with
> STANBOL-910 which I described in the latest comment. If I don't get any
> feedback I'll go for the suggested approach of merging the two
> viewable-writer modules but I can live perfectly well we the other
> described approach (separate rdfviewable-writer module).
>
I am -1 for making the Stanbol UI depending on LDpath. Simple because
I do not see a good reason why one would need such an dependency.
I also think that commons.ldpathtemplate should be removed as soon as
we switch to a newer LDpath version for that the ldpathtemplate code
is available as bundle in maven central. I plan to work on the upgrade
to the newest LDpath version as soon as the first version with the
org.apache.marmotta.ldpath packages is released. This was also the
reason why I tried to remove all other functionality out of this
bundle. Now with the new LdRenderer this will be no longer possible -
but maybe thats ok as I do not see an other module where the
LdRenderer fits well.
Having an own commons/freemaker module is IMO a good ides, as it
solves the issue that commons.web.core embeds and exports freemaker.
It can also be handy if we want to seperate the WebUI from the RESTful
services at a later point in time.
best
Rupert
> Cheers,
> Reto
>
> On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ <christ.fabian@googlemail.com
>> wrote:
>
>> Hi,
>>
>> I agree that we should avoid to work on many things in parallel. Try
>> to implement and commit things step by step. Otherwise things are hard
>> to follow and not easy to revert if discussion come up.
>>
>> To the situation at hand: I can not say anything on the technical
>> level to the concrete problem. Are you now in the position Reto to
>> work around the refactoring and make the usermanager work again for
>> you? Once it runs again - we should find a consensus how things should
>> be changed.
>>
>> Best,
>> - Fabian
>>
>> 2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
>> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
>> > <ru...@gmail.com> wrote:
>> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
>> wrote:
>> >>>
>> >>> Please just restore the original LdRenderer service an the
>> >>> corresponding version of the UserManager. We can add an
>> >>> RdfViewablRenderer service later, I think its overarchitecture to
>> >>> separate out the LDVieable implementation. But first things first:
>> >>> restore the better status quo ante with the Ldrenderer.
>> >>
>> >> LDRenderer was in ldpathtemplate; I created a new module, added those
>> >> to bundlelists (both in trunk and a branch); changed exports and
>> >> import statements that are now conflicting with an lot of additional
>> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
>> >> think reverting is no longer an option as it would take longer as
>> >> implementing the service as suggested above.
>> >
>> > I think we should avoid working on an issue while dependent issues
>> > aren't resolved.
>> >
>> > Also removing the LDRenderer service was not something which was clear
>> > that this would happen neither from the description of the issue nor
>> > from the discussion on the list.
>> >
>> > As you refuse to do it, I'll read the LdRenderer service (using your
>> > new TemplateLoader service) so that UserManager can be reverted to
>> > where the code was both more elegant and working.
>> >
>> > Reto
>> >>
>> >> best
>> >> Rupert
>> >>
>> >> --
>> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> >> | Bodenlehenstraße 11 ++43-699-11108907
>> >> | A-5500 Bischofshofen
>>
>>
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi,
I did some re-refactoring yesterday to me there's one open point with
STANBOL-910 which I described in the latest comment. If I don't get any
feedback I'll go for the suggested approach of merging the two
viewable-writer modules but I can live perfectly well we the other
described approach (separate rdfviewable-writer module).
Cheers,
Reto
On Thu, Feb 14, 2013 at 2:35 PM, Fabian Christ <christ.fabian@googlemail.com
> wrote:
> Hi,
>
> I agree that we should avoid to work on many things in parallel. Try
> to implement and commit things step by step. Otherwise things are hard
> to follow and not easy to revert if discussion come up.
>
> To the situation at hand: I can not say anything on the technical
> level to the concrete problem. Are you now in the position Reto to
> work around the refactoring and make the usermanager work again for
> you? Once it runs again - we should find a consensus how things should
> be changed.
>
> Best,
> - Fabian
>
> 2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
> > On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
> > <ru...@gmail.com> wrote:
> >> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com>
> wrote:
> >>>
> >>> Please just restore the original LdRenderer service an the
> >>> corresponding version of the UserManager. We can add an
> >>> RdfViewablRenderer service later, I think its overarchitecture to
> >>> separate out the LDVieable implementation. But first things first:
> >>> restore the better status quo ante with the Ldrenderer.
> >>
> >> LDRenderer was in ldpathtemplate; I created a new module, added those
> >> to bundlelists (both in trunk and a branch); changed exports and
> >> import statements that are now conflicting with an lot of additional
> >> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
> >> think reverting is no longer an option as it would take longer as
> >> implementing the service as suggested above.
> >
> > I think we should avoid working on an issue while dependent issues
> > aren't resolved.
> >
> > Also removing the LDRenderer service was not something which was clear
> > that this would happen neither from the description of the issue nor
> > from the discussion on the list.
> >
> > As you refuse to do it, I'll read the LdRenderer service (using your
> > new TemplateLoader service) so that UserManager can be reverted to
> > where the code was both more elegant and working.
> >
> > Reto
> >>
> >> best
> >> Rupert
> >>
> >> --
> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
> >> | Bodenlehenstraße 11 ++43-699-11108907
> >> | A-5500 Bischofshofen
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Danny Ayers <da...@gmail.com>.
On 14 February 2013 14:35, Fabian Christ <ch...@googlemail.com> wrote:
Are you now in the position Reto to
> work around the refactoring and make the usermanager work again for
> you?
It's working fine for me now following Reto's latest adjustments.
I'm hoping to get some good hours in on it in the next few days:
tweaks, tests, more features, tests. Should start with some patches
this evening.
Cheers,
Danny.
--
http://dannyayers.com
http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
I agree that we should avoid to work on many things in parallel. Try
to implement and commit things step by step. Otherwise things are hard
to follow and not easy to revert if discussion come up.
To the situation at hand: I can not say anything on the technical
level to the concrete problem. Are you now in the position Reto to
work around the refactoring and make the usermanager work again for
you? Once it runs again - we should find a consensus how things should
be changed.
Best,
- Fabian
2013/2/13 Reto Bachmann-Gmür <re...@apache.org>:
> On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
> <ru...@gmail.com> wrote:
>> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com> wrote:
>>>
>>> Please just restore the original LdRenderer service an the
>>> corresponding version of the UserManager. We can add an
>>> RdfViewablRenderer service later, I think its overarchitecture to
>>> separate out the LDVieable implementation. But first things first:
>>> restore the better status quo ante with the Ldrenderer.
>>
>> LDRenderer was in ldpathtemplate; I created a new module, added those
>> to bundlelists (both in trunk and a branch); changed exports and
>> import statements that are now conflicting with an lot of additional
>> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
>> think reverting is no longer an option as it would take longer as
>> implementing the service as suggested above.
>
> I think we should avoid working on an issue while dependent issues
> aren't resolved.
>
> Also removing the LDRenderer service was not something which was clear
> that this would happen neither from the description of the issue nor
> from the discussion on the list.
>
> As you refuse to do it, I'll read the LdRenderer service (using your
> new TemplateLoader service) so that UserManager can be reverted to
> where the code was both more elegant and working.
>
> Reto
>>
>> best
>> Rupert
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
--
Fabian
http://twitter.com/fctwitt
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Wed, Feb 13, 2013 at 3:18 PM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com> wrote:
>>
>> Please just restore the original LdRenderer service an the
>> corresponding version of the UserManager. We can add an
>> RdfViewablRenderer service later, I think its overarchitecture to
>> separate out the LDVieable implementation. But first things first:
>> restore the better status quo ante with the Ldrenderer.
>
> LDRenderer was in ldpathtemplate; I created a new module, added those
> to bundlelists (both in trunk and a branch); changed exports and
> import statements that are now conflicting with an lot of additional
> changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
> think reverting is no longer an option as it would take longer as
> implementing the service as suggested above.
I think we should avoid working on an issue while dependent issues
aren't resolved.
Also removing the LDRenderer service was not something which was clear
that this would happen neither from the description of the issue nor
from the discussion on the list.
As you refuse to do it, I'll read the LdRenderer service (using your
new TemplateLoader service) so that UserManager can be reverted to
where the code was both more elegant and working.
Reto
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Wed, Feb 13, 2013 at 3:12 PM, Reto Bachmann-Gmür <re...@wymiwyg.com> wrote:
>
> Please just restore the original LdRenderer service an the
> corresponding version of the UserManager. We can add an
> RdfViewablRenderer service later, I think its overarchitecture to
> separate out the LDVieable implementation. But first things first:
> restore the better status quo ante with the Ldrenderer.
LDRenderer was in ldpathtemplate; I created a new module, added those
to bundlelists (both in trunk and a branch); changed exports and
import statements that are now conflicting with an lot of additional
changes I made while working on STANBOL-924 and STANBOL-927. Sorry I
think reverting is no longer an option as it would take longer as
implementing the service as suggested above.
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Wed, Feb 13, 2013 at 2:59 PM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> We should just has a service that takes an
>> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
>> first to sencond in the third.
>
> Than define this interface in
>
> <groupId>org.apache.stanbol</groupId>
> <artifactId>org.apache.stanbol.commons.web.viewable</artifactId>
>
> org.apache.stanbol.commons.web.viewable.RdfViewableRenderer
> + render(RdfVieweble rdfViewable, OutpuStream out, MediaType mt)
>
> and provide an LDpath based implementation in
>
> <groupId>org.apache.stanbol</groupId>
> <artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
>
> Internally the LdViewableWriter should than be adapted to also use this service.
>
> In the meantime I will commit my current version as the UserManager
> does work nice locally
If by that you mean the version in which the usermanager takes care
about the ld-details I strongly disagree.
Please just restore the original LdRenderer service an the
corresponding version of the UserManager. We can add an
RdfViewablRenderer service later, I think its overarchitecture to
separate out the LDVieable implementation. But first things first:
restore the better status quo ante with the Ldrenderer.
Cheers,
Reto
>
> best
> Rupert
>
>
> On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> Hi Rupert
>>
>> On Wed, Feb 13, 2013 at 2:22 PM, Rupert Westenthaler
>> <ru...@gmail.com> wrote:
>>> Hi Danny, Reto
>>>
>>> I have not introduced a dependency to Freemaker nor JAX-RS. This
>>> dependency was always present - transitive over the LDRenderer and via
>>> the dependency to commons.web.base.
>>
>> I'm talking about the java class. The class was written on higher
>> level of abstraction without dependency on these.
>>
>> Also I think it should be best practice not to rely on transitive
>> dependencies. If an artifact is using classes from another artifact we
>> should explicitly depend on it. But that's another story.
>>
>>
>>>
>>> Also the "org/apache/stanbol/commons/usermanagement/webConsole.ftl"
>>> used to render things
>>>
>>>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>>>> javax.ws.rs.WebApplicationException:
>>>> com.sun.jersey.api.MessageException: A message body writer for Java
>>>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>>>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>>>> MIME media type application/octet-stream was not found
>>>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>>>
>>> This could indicates that you are missing
>>>
>>> <groupId>org.apache.stanbol</groupId>
>>> <artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
>>> <version>0.12.0-SNAPSHOT</version>
>>>
>>> in your launcher. But also the mime type "application/octet-stream"
>>> mentioned in the exception is not compatible with "text/html"
>>> supported by the JAX-RS writer for RdfViewable. Because of that I
>>> think that this is more related to the Accept header of your request.
>>>
>>> I agree that having a direct dependency to an JAX-RS writer class is
>>> not a good thing. Because of that I suggest to adapt the
>>> WebConsolePlugin so that it can render the Graph itself.
>>>
>>> private TemplateEngine<Resource> templateEngine;
>>>
>>> @Override
>>> public void activate(BundleContext bundleContext) {
>>> super.activate(bundleContext);
>>> //use some getter to get the Graph that backups the UserManager
>>> //TODO: a direct getter for the graph would be nice to have
>>> templateEngine = new TemplateEngine<Resource>(
>>> new ClerezzaBackend(userManager.getUserType().getGraph()));
>>> templateEngine.setTemplateLoader(templateLoader);
>>> }
>>>
>>> and
>>>
>>> protected void renderContent(HttpServletRequest req,
>>> HttpServletResponse response) throws ServletException, IOException {
>>> try {
>>> templateEngine.processFileTemplate(userManager.getUserType().getNode(),
>>>
>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>> response.getWriter());
>>> response.getWriter().flush();
>>> } catch (.. handle Exceptions ..){}
>>> }
>>>
>>> WDYT
>>
>> I think that this is ugly. We should just has a service that takes an
>> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
>> first to sencond in the third. Or less nice but better than what we
>> have now the LdRendere Service taking a GraphNode, a template-path and
>> an OutputStream. Havin Both services wouldn't harm either, the first
>> abstracting away from LdPathTemplates the latter being LdPath
>> specific.
>>
>> So to recap:
>> - http://localhost:8080/system/console/usermanagement was working till
>> your refactoring
>> - WebConsolePlugin didn't reference any Freemarker class
>> - WebConsolePlugin didn't reference any JAX-RS specific class
>> - WebConsolePlugin could have been improved by not invoking an LdPath
>> specifc rendering service but a service to render RdfViewable (an
>> which might in future support different template formats)
>>
>> In my opinion both the changes you committed as well as the one you
>> proposed go in the wrong direction.
>>
>> Reto
>>
>>> Rupert
>>>
>>> On Wed, Feb 13, 2013 at 12:44 PM, Danny Ayers <da...@gmail.com> wrote:
>>>> On 13 February 2013 12:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>>> In between Danny you could you write some tests for the Usermanager?
>>>>> With a test the trunk version would probably not have been broken.
>>>>
>>>> Will do.
>>>>
>>>> --
>>>> http://dannyayers.com
>>>>
>>>> http://webbeep.it - text to tones and back again
>>>
>>>
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> We should just has a service that takes an
> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
> first to sencond in the third.
Than define this interface in
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.commons.web.viewable</artifactId>
org.apache.stanbol.commons.web.viewable.RdfViewableRenderer
+ render(RdfVieweble rdfViewable, OutpuStream out, MediaType mt)
and provide an LDpath based implementation in
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
Internally the LdViewableWriter should than be adapted to also use this service.
In the meantime I will commit my current version as the UserManager
does work nice locally
best
Rupert
On Wed, Feb 13, 2013 at 2:45 PM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi Rupert
>
> On Wed, Feb 13, 2013 at 2:22 PM, Rupert Westenthaler
> <ru...@gmail.com> wrote:
>> Hi Danny, Reto
>>
>> I have not introduced a dependency to Freemaker nor JAX-RS. This
>> dependency was always present - transitive over the LDRenderer and via
>> the dependency to commons.web.base.
>
> I'm talking about the java class. The class was written on higher
> level of abstraction without dependency on these.
>
> Also I think it should be best practice not to rely on transitive
> dependencies. If an artifact is using classes from another artifact we
> should explicitly depend on it. But that's another story.
>
>
>>
>> Also the "org/apache/stanbol/commons/usermanagement/webConsole.ftl"
>> used to render things
>>
>>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>>> javax.ws.rs.WebApplicationException:
>>> com.sun.jersey.api.MessageException: A message body writer for Java
>>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>>> MIME media type application/octet-stream was not found
>>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>>
>> This could indicates that you are missing
>>
>> <groupId>org.apache.stanbol</groupId>
>> <artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
>> <version>0.12.0-SNAPSHOT</version>
>>
>> in your launcher. But also the mime type "application/octet-stream"
>> mentioned in the exception is not compatible with "text/html"
>> supported by the JAX-RS writer for RdfViewable. Because of that I
>> think that this is more related to the Accept header of your request.
>>
>> I agree that having a direct dependency to an JAX-RS writer class is
>> not a good thing. Because of that I suggest to adapt the
>> WebConsolePlugin so that it can render the Graph itself.
>>
>> private TemplateEngine<Resource> templateEngine;
>>
>> @Override
>> public void activate(BundleContext bundleContext) {
>> super.activate(bundleContext);
>> //use some getter to get the Graph that backups the UserManager
>> //TODO: a direct getter for the graph would be nice to have
>> templateEngine = new TemplateEngine<Resource>(
>> new ClerezzaBackend(userManager.getUserType().getGraph()));
>> templateEngine.setTemplateLoader(templateLoader);
>> }
>>
>> and
>>
>> protected void renderContent(HttpServletRequest req,
>> HttpServletResponse response) throws ServletException, IOException {
>> try {
>> templateEngine.processFileTemplate(userManager.getUserType().getNode(),
>>
>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>> response.getWriter());
>> response.getWriter().flush();
>> } catch (.. handle Exceptions ..){}
>> }
>>
>> WDYT
>
> I think that this is ugly. We should just has a service that takes an
> RdfVieweble, an OutpuStream and a MediaTypea and which writer the
> first to sencond in the third. Or less nice but better than what we
> have now the LdRendere Service taking a GraphNode, a template-path and
> an OutputStream. Havin Both services wouldn't harm either, the first
> abstracting away from LdPathTemplates the latter being LdPath
> specific.
>
> So to recap:
> - http://localhost:8080/system/console/usermanagement was working till
> your refactoring
> - WebConsolePlugin didn't reference any Freemarker class
> - WebConsolePlugin didn't reference any JAX-RS specific class
> - WebConsolePlugin could have been improved by not invoking an LdPath
> specifc rendering service but a service to render RdfViewable (an
> which might in future support different template formats)
>
> In my opinion both the changes you committed as well as the one you
> proposed go in the wrong direction.
>
> Reto
>
>> Rupert
>>
>> On Wed, Feb 13, 2013 at 12:44 PM, Danny Ayers <da...@gmail.com> wrote:
>>> On 13 February 2013 12:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>> In between Danny you could you write some tests for the Usermanager?
>>>> With a test the trunk version would probably not have been broken.
>>>
>>> Will do.
>>>
>>> --
>>> http://dannyayers.com
>>>
>>> http://webbeep.it - text to tones and back again
>>
>>
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Rupert
On Wed, Feb 13, 2013 at 2:22 PM, Rupert Westenthaler
<ru...@gmail.com> wrote:
> Hi Danny, Reto
>
> I have not introduced a dependency to Freemaker nor JAX-RS. This
> dependency was always present - transitive over the LDRenderer and via
> the dependency to commons.web.base.
I'm talking about the java class. The class was written on higher
level of abstraction without dependency on these.
Also I think it should be best practice not to rely on transitive
dependencies. If an artifact is using classes from another artifact we
should explicitly depend on it. But that's another story.
>
> Also the "org/apache/stanbol/commons/usermanagement/webConsole.ftl"
> used to render things
>
>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>> javax.ws.rs.WebApplicationException:
>> com.sun.jersey.api.MessageException: A message body writer for Java
>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>> MIME media type application/octet-stream was not found
>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>
> This could indicates that you are missing
>
> <groupId>org.apache.stanbol</groupId>
> <artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
> <version>0.12.0-SNAPSHOT</version>
>
> in your launcher. But also the mime type "application/octet-stream"
> mentioned in the exception is not compatible with "text/html"
> supported by the JAX-RS writer for RdfViewable. Because of that I
> think that this is more related to the Accept header of your request.
>
> I agree that having a direct dependency to an JAX-RS writer class is
> not a good thing. Because of that I suggest to adapt the
> WebConsolePlugin so that it can render the Graph itself.
>
> private TemplateEngine<Resource> templateEngine;
>
> @Override
> public void activate(BundleContext bundleContext) {
> super.activate(bundleContext);
> //use some getter to get the Graph that backups the UserManager
> //TODO: a direct getter for the graph would be nice to have
> templateEngine = new TemplateEngine<Resource>(
> new ClerezzaBackend(userManager.getUserType().getGraph()));
> templateEngine.setTemplateLoader(templateLoader);
> }
>
> and
>
> protected void renderContent(HttpServletRequest req,
> HttpServletResponse response) throws ServletException, IOException {
> try {
> templateEngine.processFileTemplate(userManager.getUserType().getNode(),
>
> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
> response.getWriter());
> response.getWriter().flush();
> } catch (.. handle Exceptions ..){}
> }
>
> WDYT
I think that this is ugly. We should just has a service that takes an
RdfVieweble, an OutpuStream and a MediaTypea and which writer the
first to sencond in the third. Or less nice but better than what we
have now the LdRendere Service taking a GraphNode, a template-path and
an OutputStream. Havin Both services wouldn't harm either, the first
abstracting away from LdPathTemplates the latter being LdPath
specific.
So to recap:
- http://localhost:8080/system/console/usermanagement was working till
your refactoring
- WebConsolePlugin didn't reference any Freemarker class
- WebConsolePlugin didn't reference any JAX-RS specific class
- WebConsolePlugin could have been improved by not invoking an LdPath
specifc rendering service but a service to render RdfViewable (an
which might in future support different template formats)
In my opinion both the changes you committed as well as the one you
proposed go in the wrong direction.
Reto
> Rupert
>
> On Wed, Feb 13, 2013 at 12:44 PM, Danny Ayers <da...@gmail.com> wrote:
>> On 13 February 2013 12:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>> In between Danny you could you write some tests for the Usermanager?
>>> With a test the trunk version would probably not have been broken.
>>
>> Will do.
>>
>> --
>> http://dannyayers.com
>>
>> http://webbeep.it - text to tones and back again
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Danny, Reto
I have not introduced a dependency to Freemaker nor JAX-RS. This
dependency was always present - transitive over the LDRenderer and via
the dependency to commons.web.base.
Also the "org/apache/stanbol/commons/usermanagement/webConsole.ftl"
used to render things
> SEVERE: Mapped exception to response: 500 (Internal Server Error)
> javax.ws.rs.WebApplicationException:
> com.sun.jersey.api.MessageException: A message body writer for Java
> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
> MIME media type application/octet-stream was not found
> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
This could indicates that you are missing
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.commons.web.viewable.ldpath</artifactId>
<version>0.12.0-SNAPSHOT</version>
in your launcher. But also the mime type "application/octet-stream"
mentioned in the exception is not compatible with "text/html"
supported by the JAX-RS writer for RdfViewable. Because of that I
think that this is more related to the Accept header of your request.
I agree that having a direct dependency to an JAX-RS writer class is
not a good thing. Because of that I suggest to adapt the
WebConsolePlugin so that it can render the Graph itself.
private TemplateEngine<Resource> templateEngine;
@Override
public void activate(BundleContext bundleContext) {
super.activate(bundleContext);
//use some getter to get the Graph that backups the UserManager
//TODO: a direct getter for the graph would be nice to have
templateEngine = new TemplateEngine<Resource>(
new ClerezzaBackend(userManager.getUserType().getGraph()));
templateEngine.setTemplateLoader(templateLoader);
}
and
protected void renderContent(HttpServletRequest req,
HttpServletResponse response) throws ServletException, IOException {
try {
templateEngine.processFileTemplate(userManager.getUserType().getNode(),
"org/apache/stanbol/commons/usermanagement/webConsole.ftl",
response.getWriter());
response.getWriter().flush();
} catch (.. handle Exceptions ..){}
}
WDYT
Rupert
On Wed, Feb 13, 2013 at 12:44 PM, Danny Ayers <da...@gmail.com> wrote:
> On 13 February 2013 12:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> In between Danny you could you write some tests for the Usermanager?
>> With a test the trunk version would probably not have been broken.
>
> Will do.
>
> --
> http://dannyayers.com
>
> http://webbeep.it - text to tones and back again
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Danny Ayers <da...@gmail.com>.
On 13 February 2013 12:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
> In between Danny you could you write some tests for the Usermanager?
> With a test the trunk version would probably not have been broken.
Will do.
--
http://dannyayers.com
http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
In between Danny you could you write some tests for the Usermanager?
With a test the trunk version would probably not have been broken.
Cheers,
Reto
On Wed, Feb 13, 2013 at 12:22 PM, Danny Ayers <da...@gmail.com> wrote:
> Whichever way you prefer to go further on Rupert, could you please
> revert that single file in the interim, it is a blocker for me.
>
> On 13 February 2013 12:17, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> Hello,
>>
>> In the discussion about the refactoring would drop the LdRenderer
>> Service without replacement. I understood the proposal as to unpinning
>> Freemarker stuff from the LdRenderer (which admittedly was at the
>> wrong place). I think a service to Render RdfViewables is needed and
>> that such a service should be independent of Jax-Rs. Apart from being
>> broken I think the refactored WebConsolePlugin code is also
>> significantly less nice than the original version. It introduced a
>> dependency on jax-rs and to freemarker which weren't there before. I
>> think this stuff should be abstracted away.
>>
>> Rupert could you please reintroduce a service equivalent to LdRenderer
>> to serialize RdfViewables to Stream without having to care about
>> jax-rs or Freemarker classes? As I already pointed out in my mail to
>> the original thread there is nothing web-specific in such a service.
>>
>> Cheers,
>> Reto
>>
>> On Wed, Feb 13, 2013 at 11:51 AM, Danny Ayers <da...@gmail.com> wrote:
>>> note also the API access is also broken, running:
>>>
>>> curl --user admin:admin -H "Accept:text/turtle"
>>> http://localhost:8080/user-management/user/anonymous
>>>
>>> throws:
>>>
>>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>>> javax.ws.rs.WebApplicationException:
>>> com.sun.jersey.api.MessageException: A message body writer for Java
>>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>>> MIME media type application/octet-stream was not found
>>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>>> ...
>>>
>>> On 13 February 2013 11:45, Danny Ayers <da...@gmail.com> wrote:
>>>> The root of the problem making User Management totally unusable is the
>>>> latest change made at:
>>>>
>>>> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/usermanagement/src/main/java/org/apache/stanbol/commons/usermanagement/WebConsolePlugin.java?view=log
>>>>
>>>> associated with:
>>>> STANBOL-910
>>>> Refactor Viewable and LDpath Freemaker Template rendering
>>>>
>>>> (The previous version used a LdRenderer, the latest uses a LdViewableWriter)
>>>>
>>>> Would it please be possible to revert this change (or refactor to a
>>>> working state).
>>>>
>>>> Thanks,
>>>> Danny.
>>>>
>>>> On 13 February 2013 11:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>>> Clearly something seems quite weird of using the MessageBodyWriter
>>>>> which should be a service for JAX-RS in this non JAX-RS context. The
>>>>> Original Version was directly accessing LdRenderer.
>>>>>
>>>>> You should see when this changed and maybe reopen the issue the change
>>>>> was associated with.
>>>>>
>>>>> Cheers,
>>>>> Reto
>>>>>
>>>>> On Wed, Feb 13, 2013 at 11:16 AM, Danny Ayers <da...@gmail.com> wrote:
>>>>>> will do.
>>>>>>
>>>>>> On 13 February 2013 11:12, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I see the problem too.
>>>>>>>
>>>>>>> Can you create an issue to address this?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Reto
>>>>>>>
>>>>>>> On Tue, Feb 12, 2013 at 3:54 PM, Danny Ayers <da...@gmail.com> wrote:
>>>>>>>> [I'll post again later re. User Management module more generally, re.
>>>>>>>> STANBOL-897, but before going any further I could do with a working
>>>>>>>> system :) ]
>>>>>>>>
>>>>>>>> From a checkout & install from svn, I believe a pristine system, when
>>>>>>>> I click on the User Management tab I'm getting a 500:
>>>>>>>>
>>>>>>>> java.lang.IllegalStateException: WRITER
>>>>>>>> at org.mortbay.jetty.Response.getOutputStream(Response.java:594)
>>>>>>>> at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:112)
>>>>>>>> at org.apache.stanbol.commons.usermanagement.WebConsolePlugin.renderContent(WebConsolePlugin.java:79)
>>>>>>>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:155)
>>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>>>>>>> ...
>>>>>>>>
>>>>>>>> When I was working from a git clone of a git clone of the svn (!) this
>>>>>>>> wasn't happening, but I haven't been able to track down what's
>>>>>>>> changed.
>>>>>>>>
>>>>>>>> Possibly related is this message on startup:
>>>>>>>>
>>>>>>>> WARNING: A HTTP GET method, public void
>>>>>>>> org.apache.clerezza.platform.security.permissioncheck.PermissionCheck.checkPermission(java.lang.String),
>>>>>>>> MUST return a non-void type.
>>>>>>>>
>>>>>>>> The call which leads to the 500 is:
>>>>>>>>
>>>>>>>> private LdViewableWriter rdfViewableWriter;
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> RdfViewable rdfViewable = new RdfViewable(
>>>>>>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>>>>>>> userManager.getUserType());
>>>>>>>>
>>>>>>>> rdfViewableWriter.writeTo(rdfViewable, RdfViewable.class,
>>>>>>>> RdfViewable.class,
>>>>>>>> RdfViewable.class.getAnnotations(), MediaType.TEXT_HTML_TYPE,
>>>>>>>> null, response.getOutputStream());
>>>>>>>>
>>>>>>>> I've tried a dummy .ftl - that didn't change anything, and
>>>>>>>> userManager.getUserType() is producing an appropriate value (a
>>>>>>>> foaf:Agent).
>>>>>>>>
>>>>>>>> I vaguely remember this kind of exception arising when you try
>>>>>>>> writing to a closed stream. But there's so much filter chaining going
>>>>>>>> on, and not a little magic, it's really hard to see what's going
>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Danny.
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://dannyayers.com
>>>>>>>>
>>>>>>>> http://webbeep.it - text to tones and back again
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://dannyayers.com
>>>>>>
>>>>>> http://webbeep.it - text to tones and back again
>>>>
>>>>
>>>>
>>>> --
>>>> http://dannyayers.com
>>>>
>>>> http://webbeep.it - text to tones and back again
>>>
>>>
>>>
>>> --
>>> http://dannyayers.com
>>>
>>> http://webbeep.it - text to tones and back again
>
>
>
> --
> http://dannyayers.com
>
> http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Danny Ayers <da...@gmail.com>.
Whichever way you prefer to go further on Rupert, could you please
revert that single file in the interim, it is a blocker for me.
On 13 February 2013 12:17, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hello,
>
> In the discussion about the refactoring would drop the LdRenderer
> Service without replacement. I understood the proposal as to unpinning
> Freemarker stuff from the LdRenderer (which admittedly was at the
> wrong place). I think a service to Render RdfViewables is needed and
> that such a service should be independent of Jax-Rs. Apart from being
> broken I think the refactored WebConsolePlugin code is also
> significantly less nice than the original version. It introduced a
> dependency on jax-rs and to freemarker which weren't there before. I
> think this stuff should be abstracted away.
>
> Rupert could you please reintroduce a service equivalent to LdRenderer
> to serialize RdfViewables to Stream without having to care about
> jax-rs or Freemarker classes? As I already pointed out in my mail to
> the original thread there is nothing web-specific in such a service.
>
> Cheers,
> Reto
>
> On Wed, Feb 13, 2013 at 11:51 AM, Danny Ayers <da...@gmail.com> wrote:
>> note also the API access is also broken, running:
>>
>> curl --user admin:admin -H "Accept:text/turtle"
>> http://localhost:8080/user-management/user/anonymous
>>
>> throws:
>>
>> SEVERE: Mapped exception to response: 500 (Internal Server Error)
>> javax.ws.rs.WebApplicationException:
>> com.sun.jersey.api.MessageException: A message body writer for Java
>> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
>> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
>> MIME media type application/octet-stream was not found
>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
>> ...
>>
>> On 13 February 2013 11:45, Danny Ayers <da...@gmail.com> wrote:
>>> The root of the problem making User Management totally unusable is the
>>> latest change made at:
>>>
>>> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/usermanagement/src/main/java/org/apache/stanbol/commons/usermanagement/WebConsolePlugin.java?view=log
>>>
>>> associated with:
>>> STANBOL-910
>>> Refactor Viewable and LDpath Freemaker Template rendering
>>>
>>> (The previous version used a LdRenderer, the latest uses a LdViewableWriter)
>>>
>>> Would it please be possible to revert this change (or refactor to a
>>> working state).
>>>
>>> Thanks,
>>> Danny.
>>>
>>> On 13 February 2013 11:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>> Clearly something seems quite weird of using the MessageBodyWriter
>>>> which should be a service for JAX-RS in this non JAX-RS context. The
>>>> Original Version was directly accessing LdRenderer.
>>>>
>>>> You should see when this changed and maybe reopen the issue the change
>>>> was associated with.
>>>>
>>>> Cheers,
>>>> Reto
>>>>
>>>> On Wed, Feb 13, 2013 at 11:16 AM, Danny Ayers <da...@gmail.com> wrote:
>>>>> will do.
>>>>>
>>>>> On 13 February 2013 11:12, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>>>> Hi
>>>>>>
>>>>>> I see the problem too.
>>>>>>
>>>>>> Can you create an issue to address this?
>>>>>>
>>>>>> Cheers,
>>>>>> Reto
>>>>>>
>>>>>> On Tue, Feb 12, 2013 at 3:54 PM, Danny Ayers <da...@gmail.com> wrote:
>>>>>>> [I'll post again later re. User Management module more generally, re.
>>>>>>> STANBOL-897, but before going any further I could do with a working
>>>>>>> system :) ]
>>>>>>>
>>>>>>> From a checkout & install from svn, I believe a pristine system, when
>>>>>>> I click on the User Management tab I'm getting a 500:
>>>>>>>
>>>>>>> java.lang.IllegalStateException: WRITER
>>>>>>> at org.mortbay.jetty.Response.getOutputStream(Response.java:594)
>>>>>>> at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:112)
>>>>>>> at org.apache.stanbol.commons.usermanagement.WebConsolePlugin.renderContent(WebConsolePlugin.java:79)
>>>>>>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:155)
>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>>>>>> ...
>>>>>>>
>>>>>>> When I was working from a git clone of a git clone of the svn (!) this
>>>>>>> wasn't happening, but I haven't been able to track down what's
>>>>>>> changed.
>>>>>>>
>>>>>>> Possibly related is this message on startup:
>>>>>>>
>>>>>>> WARNING: A HTTP GET method, public void
>>>>>>> org.apache.clerezza.platform.security.permissioncheck.PermissionCheck.checkPermission(java.lang.String),
>>>>>>> MUST return a non-void type.
>>>>>>>
>>>>>>> The call which leads to the 500 is:
>>>>>>>
>>>>>>> private LdViewableWriter rdfViewableWriter;
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> RdfViewable rdfViewable = new RdfViewable(
>>>>>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>>>>>> userManager.getUserType());
>>>>>>>
>>>>>>> rdfViewableWriter.writeTo(rdfViewable, RdfViewable.class,
>>>>>>> RdfViewable.class,
>>>>>>> RdfViewable.class.getAnnotations(), MediaType.TEXT_HTML_TYPE,
>>>>>>> null, response.getOutputStream());
>>>>>>>
>>>>>>> I've tried a dummy .ftl - that didn't change anything, and
>>>>>>> userManager.getUserType() is producing an appropriate value (a
>>>>>>> foaf:Agent).
>>>>>>>
>>>>>>> I vaguely remember this kind of exception arising when you try
>>>>>>> writing to a closed stream. But there's so much filter chaining going
>>>>>>> on, and not a little magic, it's really hard to see what's going
>>>>>>> wrong.
>>>>>>>
>>>>>>> Any suggestions?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Danny.
>>>>>>>
>>>>>>> --
>>>>>>> http://dannyayers.com
>>>>>>>
>>>>>>> http://webbeep.it - text to tones and back again
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://dannyayers.com
>>>>>
>>>>> http://webbeep.it - text to tones and back again
>>>
>>>
>>>
>>> --
>>> http://dannyayers.com
>>>
>>> http://webbeep.it - text to tones and back again
>>
>>
>>
>> --
>> http://dannyayers.com
>>
>> http://webbeep.it - text to tones and back again
--
http://dannyayers.com
http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hello,
In the discussion about the refactoring would drop the LdRenderer
Service without replacement. I understood the proposal as to unpinning
Freemarker stuff from the LdRenderer (which admittedly was at the
wrong place). I think a service to Render RdfViewables is needed and
that such a service should be independent of Jax-Rs. Apart from being
broken I think the refactored WebConsolePlugin code is also
significantly less nice than the original version. It introduced a
dependency on jax-rs and to freemarker which weren't there before. I
think this stuff should be abstracted away.
Rupert could you please reintroduce a service equivalent to LdRenderer
to serialize RdfViewables to Stream without having to care about
jax-rs or Freemarker classes? As I already pointed out in my mail to
the original thread there is nothing web-specific in such a service.
Cheers,
Reto
On Wed, Feb 13, 2013 at 11:51 AM, Danny Ayers <da...@gmail.com> wrote:
> note also the API access is also broken, running:
>
> curl --user admin:admin -H "Accept:text/turtle"
> http://localhost:8080/user-management/user/anonymous
>
> throws:
>
> SEVERE: Mapped exception to response: 500 (Internal Server Error)
> javax.ws.rs.WebApplicationException:
> com.sun.jersey.api.MessageException: A message body writer for Java
> class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
> type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
> MIME media type application/octet-stream was not found
> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
> ...
>
> On 13 February 2013 11:45, Danny Ayers <da...@gmail.com> wrote:
>> The root of the problem making User Management totally unusable is the
>> latest change made at:
>>
>> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/usermanagement/src/main/java/org/apache/stanbol/commons/usermanagement/WebConsolePlugin.java?view=log
>>
>> associated with:
>> STANBOL-910
>> Refactor Viewable and LDpath Freemaker Template rendering
>>
>> (The previous version used a LdRenderer, the latest uses a LdViewableWriter)
>>
>> Would it please be possible to revert this change (or refactor to a
>> working state).
>>
>> Thanks,
>> Danny.
>>
>> On 13 February 2013 11:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>> Clearly something seems quite weird of using the MessageBodyWriter
>>> which should be a service for JAX-RS in this non JAX-RS context. The
>>> Original Version was directly accessing LdRenderer.
>>>
>>> You should see when this changed and maybe reopen the issue the change
>>> was associated with.
>>>
>>> Cheers,
>>> Reto
>>>
>>> On Wed, Feb 13, 2013 at 11:16 AM, Danny Ayers <da...@gmail.com> wrote:
>>>> will do.
>>>>
>>>> On 13 February 2013 11:12, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>>> Hi
>>>>>
>>>>> I see the problem too.
>>>>>
>>>>> Can you create an issue to address this?
>>>>>
>>>>> Cheers,
>>>>> Reto
>>>>>
>>>>> On Tue, Feb 12, 2013 at 3:54 PM, Danny Ayers <da...@gmail.com> wrote:
>>>>>> [I'll post again later re. User Management module more generally, re.
>>>>>> STANBOL-897, but before going any further I could do with a working
>>>>>> system :) ]
>>>>>>
>>>>>> From a checkout & install from svn, I believe a pristine system, when
>>>>>> I click on the User Management tab I'm getting a 500:
>>>>>>
>>>>>> java.lang.IllegalStateException: WRITER
>>>>>> at org.mortbay.jetty.Response.getOutputStream(Response.java:594)
>>>>>> at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:112)
>>>>>> at org.apache.stanbol.commons.usermanagement.WebConsolePlugin.renderContent(WebConsolePlugin.java:79)
>>>>>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:155)
>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>>>>> ...
>>>>>>
>>>>>> When I was working from a git clone of a git clone of the svn (!) this
>>>>>> wasn't happening, but I haven't been able to track down what's
>>>>>> changed.
>>>>>>
>>>>>> Possibly related is this message on startup:
>>>>>>
>>>>>> WARNING: A HTTP GET method, public void
>>>>>> org.apache.clerezza.platform.security.permissioncheck.PermissionCheck.checkPermission(java.lang.String),
>>>>>> MUST return a non-void type.
>>>>>>
>>>>>> The call which leads to the 500 is:
>>>>>>
>>>>>> private LdViewableWriter rdfViewableWriter;
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> RdfViewable rdfViewable = new RdfViewable(
>>>>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>>>>> userManager.getUserType());
>>>>>>
>>>>>> rdfViewableWriter.writeTo(rdfViewable, RdfViewable.class,
>>>>>> RdfViewable.class,
>>>>>> RdfViewable.class.getAnnotations(), MediaType.TEXT_HTML_TYPE,
>>>>>> null, response.getOutputStream());
>>>>>>
>>>>>> I've tried a dummy .ftl - that didn't change anything, and
>>>>>> userManager.getUserType() is producing an appropriate value (a
>>>>>> foaf:Agent).
>>>>>>
>>>>>> I vaguely remember this kind of exception arising when you try
>>>>>> writing to a closed stream. But there's so much filter chaining going
>>>>>> on, and not a little magic, it's really hard to see what's going
>>>>>> wrong.
>>>>>>
>>>>>> Any suggestions?
>>>>>>
>>>>>> Cheers,
>>>>>> Danny.
>>>>>>
>>>>>> --
>>>>>> http://dannyayers.com
>>>>>>
>>>>>> http://webbeep.it - text to tones and back again
>>>>
>>>>
>>>>
>>>> --
>>>> http://dannyayers.com
>>>>
>>>> http://webbeep.it - text to tones and back again
>>
>>
>>
>> --
>> http://dannyayers.com
>>
>> http://webbeep.it - text to tones and back again
>
>
>
> --
> http://dannyayers.com
>
> http://webbeep.it - text to tones and back again
Re: breakage from Refactor Viewable and LDpath (was Re: User
Management/LdViewableWriter IllegalStateException)
Posted by Danny Ayers <da...@gmail.com>.
note also the API access is also broken, running:
curl --user admin:admin -H "Accept:text/turtle"
http://localhost:8080/user-management/user/anonymous
throws:
SEVERE: Mapped exception to response: 500 (Internal Server Error)
javax.ws.rs.WebApplicationException:
com.sun.jersey.api.MessageException: A message body writer for Java
class org.apache.stanbol.commons.web.viewable.RdfViewable, and Java
type class org.apache.stanbol.commons.web.viewable.RdfViewable, and
MIME media type application/octet-stream was not found
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:285)
...
On 13 February 2013 11:45, Danny Ayers <da...@gmail.com> wrote:
> The root of the problem making User Management totally unusable is the
> latest change made at:
>
> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/usermanagement/src/main/java/org/apache/stanbol/commons/usermanagement/WebConsolePlugin.java?view=log
>
> associated with:
> STANBOL-910
> Refactor Viewable and LDpath Freemaker Template rendering
>
> (The previous version used a LdRenderer, the latest uses a LdViewableWriter)
>
> Would it please be possible to revert this change (or refactor to a
> working state).
>
> Thanks,
> Danny.
>
> On 13 February 2013 11:29, Reto Bachmann-Gmür <re...@apache.org> wrote:
>> Clearly something seems quite weird of using the MessageBodyWriter
>> which should be a service for JAX-RS in this non JAX-RS context. The
>> Original Version was directly accessing LdRenderer.
>>
>> You should see when this changed and maybe reopen the issue the change
>> was associated with.
>>
>> Cheers,
>> Reto
>>
>> On Wed, Feb 13, 2013 at 11:16 AM, Danny Ayers <da...@gmail.com> wrote:
>>> will do.
>>>
>>> On 13 February 2013 11:12, Reto Bachmann-Gmür <re...@apache.org> wrote:
>>>> Hi
>>>>
>>>> I see the problem too.
>>>>
>>>> Can you create an issue to address this?
>>>>
>>>> Cheers,
>>>> Reto
>>>>
>>>> On Tue, Feb 12, 2013 at 3:54 PM, Danny Ayers <da...@gmail.com> wrote:
>>>>> [I'll post again later re. User Management module more generally, re.
>>>>> STANBOL-897, but before going any further I could do with a working
>>>>> system :) ]
>>>>>
>>>>> From a checkout & install from svn, I believe a pristine system, when
>>>>> I click on the User Management tab I'm getting a 500:
>>>>>
>>>>> java.lang.IllegalStateException: WRITER
>>>>> at org.mortbay.jetty.Response.getOutputStream(Response.java:594)
>>>>> at javax.servlet.ServletResponseWrapper.getOutputStream(ServletResponseWrapper.java:112)
>>>>> at org.apache.stanbol.commons.usermanagement.WebConsolePlugin.renderContent(WebConsolePlugin.java:79)
>>>>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:155)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>>>> ...
>>>>>
>>>>> When I was working from a git clone of a git clone of the svn (!) this
>>>>> wasn't happening, but I haven't been able to track down what's
>>>>> changed.
>>>>>
>>>>> Possibly related is this message on startup:
>>>>>
>>>>> WARNING: A HTTP GET method, public void
>>>>> org.apache.clerezza.platform.security.permissioncheck.PermissionCheck.checkPermission(java.lang.String),
>>>>> MUST return a non-void type.
>>>>>
>>>>> The call which leads to the 500 is:
>>>>>
>>>>> private LdViewableWriter rdfViewableWriter;
>>>>>
>>>>> ...
>>>>>
>>>>> RdfViewable rdfViewable = new RdfViewable(
>>>>> "org/apache/stanbol/commons/usermanagement/webConsole.ftl",
>>>>> userManager.getUserType());
>>>>>
>>>>> rdfViewableWriter.writeTo(rdfViewable, RdfViewable.class,
>>>>> RdfViewable.class,
>>>>> RdfViewable.class.getAnnotations(), MediaType.TEXT_HTML_TYPE,
>>>>> null, response.getOutputStream());
>>>>>
>>>>> I've tried a dummy .ftl - that didn't change anything, and
>>>>> userManager.getUserType() is producing an appropriate value (a
>>>>> foaf:Agent).
>>>>>
>>>>> I vaguely remember this kind of exception arising when you try
>>>>> writing to a closed stream. But there's so much filter chaining going
>>>>> on, and not a little magic, it's really hard to see what's going
>>>>> wrong.
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>> Cheers,
>>>>> Danny.
>>>>>
>>>>> --
>>>>> http://dannyayers.com
>>>>>
>>>>> http://webbeep.it - text to tones and back again
>>>
>>>
>>>
>>> --
>>> http://dannyayers.com
>>>
>>> http://webbeep.it - text to tones and back again
>
>
>
> --
> http://dannyayers.com
>
> http://webbeep.it - text to tones and back again
--
http://dannyayers.com
http://webbeep.it - text to tones and back again