Hi Rupert
On Wed, Feb 13, 2013 at 2:22 PM, Rupert Westenthaler
<[email protected]> 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 <[email protected]> wrote:
>> On 13 February 2013 12:29, Reto Bachmann-Gmür <[email protected]> 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 [email protected]
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
