On 04.01.11 22:17, "Markus Joschko" <[email protected]> wrote: >How do you get hold of the services in the JSP? Sorry I am not very >familiar with OSGI. >Is there a registry that can be used to get hold of a service?
sling.getService(com.foo.MyService.class) See also https://cwiki.apache.org/SLING/scripting-variables.html In a Java servlet it is even easier, since servlets are OSGi SCR components anyway (to be exact: they are javax.servlet.Servlet service implementations). There you can use the scr javadoc annotation style for members: /** @scr.reference */ MyService myservice; >Can services be injected into a taglib? Yes, code is like that (to get the SlingScriptHelper which is the "sling" from above): SlingBindings bindings = (SlingBindings) pageContext.getRequest().getAttribute(SlingBindings.class.getName()); SlingScriptHelper sling = bindings.getSling(); sling.getService(com.foo.MyService.class); >>You would use ACL of course that prevent people from writing into >> locations they are not allowed to. The execution of scripts (setting a >> resource type and uploading a script) is restricted/able to certain >> folders. > >Is there an example somewhere on how to do that? I would be interested. You mean ACLs? See the Jackrabbit project, e.g. http://wiki.apache.org/jackrabbit/AccessControl Or the script restriction? This is configurable on the org.apache.sling.servlets.resolver.SlingServletResolver, to configure it in the felix webconsole, you can go to http://localhost:8080/system/console/configMgr/org.apache.sling.servlets.re solver.SlingServletResolver (port and context path depend on installation). The default actually seems to be the whole repository ("/"). >Mhm, correct me if I am wrong but nt:unstructured allows the user to >define own properties on the fly as well, or? >I can name at least one security consultant who would freak out if >people can store content "uncontrolled" in the repository. Because exactly? There would be a reason that he is allowed to add or edit something in the first place. >OK, then the message is: If I want to have support for input >validation it makes sense to have custom node types (which might >inherit from nt:unstructured). Not necessarily, I would opt for validation inside servlet filters, custom POST script/servlet or sling post processor. Node types should only be used for things that you know are really fixed and won't change much in the future. Such as the common nt:file and nt:folder definitions in the JCR spec. >That's where I see the types. They ensure that mandatory properties >are ... mandatory. >If in the future certain properties become optional it'll still be >possible to introduce these checks. But not if these are enforced at the data layer and a (difficult) schema change is needed to make them optional. You can change node types or update node type definitions in JCR, but as in any repository/database, this is not always trivial. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
