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.

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]
>

Reply via email to