On Fri, Nov 11, 2011 at 7:16 PM, Justin Edelson <[email protected]> wrote: > On Fri, Nov 11, 2011 at 6:42 PM, Carsten Ziegeler <[email protected]> > wrote: >> 2011/11/11 Justin Edelson <[email protected]>: >>> A configuration printer is certainly an option, but I think the devs >>> I've see run into this problem would be better served by something >>> more interactive. So let's say both :) >> +1 >> >>> >>> I'm not opposed to a metadata file, but the reason I prefer the >>> service property method to a file in META-INF is that we can reuse the >>> service properties from AdapterFactory implementations. The Web >>> Console doesn't need to care whether the metadata is provided by a >>> metadata provider service or an AdapterFactory service (or some other >>> arbitrary service). See https://gist.github.com/1359911 for an example >>> of the Web Console plugin I built as a POC. >> Hmm, I'm not a fan of declaring a service just for the sake to provide >> meta information :) >> But we could use the annotations to just generate meta type info, by >> just using the Component annotation with ds=false. > > That's worse IMHO. You convinced me - we should use a sidecar file.
https://gist.github.com/1359997 WDYT? > > Justin > >> >> Carsten >> >>> >>> Justin >>> >>> On Fri, Nov 11, 2011 at 6:08 PM, Carsten Ziegeler <[email protected]> >>> wrote: >>>> Great idea and I'm definitely +1 on such a web console plugin. Not >>>> sure if this is a web console plugin or a configuration status >>>> renderer (we need the last one as well). >>>> >>>> I think instead of defining the additional metadata through the java >>>> annotations with additional classes like the >>>> JcrNodeResourceAdapterMeta in your example, what about having a meta >>>> data file in META-INF of the bundle instead. I know its separate from >>>> the java code though. >>>> >>>> Regards >>>> Carsten >>>> >>>> 2011/11/11 Justin Edelson <[email protected]>: >>>>> Working with new Sling developers, I find that one of the concepts >>>>> they have trouble with is in the area of Adapters and that it is hard >>>>> to find out what objects are adaptable to which classes. Although it >>>>> is possible to document this (see for example >>>>> http://dev.day.com/docs/en/cq/current/developing/sling-adapters.html), >>>>> because new Adapters can be dynamically added (or removed) through >>>>> OSGi services, any documentation is potentially incomplete. >>>>> >>>>> What I would like to do is create a new Web Console plugin which >>>>> displays the list of available adaptation pairs. I'm still thinking >>>>> about the UI, but you could imagine that a first version would be a >>>>> select list on the left listing the adaptable classes and a list on >>>>> the right of the possible adapters for the selected adaptable. >>>>> >>>>> For implementations of AdapterFactory, the necessary metadata already >>>>> exists in the service registry, but for cases where a class implements >>>>> its own adapters, this metadata needs to be added. >>>>> >>>>> In order to do this, I propose the following: >>>>> 1) The creation of such a Web Console plugin (obviously). >>>>> 2) The creation of new OSGi Services for classes which implement their >>>>> own adaptations. For example: >>>>> @Component >>>>> @Service(value=Object.class) >>>>> @Properties({ >>>>> @Property(name="adaptables", >>>>> value="org.apache.sling.api.resource.Resource"), >>>>> @Property(name="adapters", value={ >>>>> "javax.jcr.Node", >>>>> "javax.jcr.Item", >>>>> "java.io.InputStream", >>>>> "java.net.URL", >>>>> "java.util.Map", >>>>> "org.apache.sling.api.resource.ValueMap" >>>>> }) >>>>> }) >>>>> public class JcrNodeResourceAdapterMeta { } >>>>> >>>>> 3) The establishment of a new service property, named >>>>> adapter.condition, which optionally indicates the conditions under >>>>> which an adaptation can be made. For example, in the case above: >>>>> @Property(name="adapter.condition", value="If the resource is a >>>>> JcrNodeResource") >>>>> >>>>> The Web Console plugin would need to note that potentially not all >>>>> adapters are listed, but I believe that if we add the metadata for all >>>>> the adapters in Sling, that will set a good precedent for downstream >>>>> projects to follow. If we want, we could also add a note which says >>>>> "If there's an adapter not listed here, please file an issue with the >>>>> adapter provider." :) >>>>> >>>>> Adding this metadata is not a trivial amount of effort, but it also >>>>> something I feel will pay dividends down the road. >>>>> >>>>> WDYT? >>>>> >>>>> Justin >>>>> >>>> >>>> >>>> >>>> -- >>>> Carsten Ziegeler >>>> [email protected] >>>> >>> >> >> >> >> -- >> Carsten Ziegeler >> [email protected] >> >
