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