brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: Entity visibility
Date Tue, 12 Aug 2014 14:56:32 GMT
+1 to Duncan's request.

Not convinced Doclet is the right tool. Feels like we really need 
reflection to get annotations + the actual values of the config keys.

For example, the following code defines a ConfigKey. From that, we want 
to extract the simple name in the annotation, the full name, the 
description and the default value. The best way to do that is to get the 
ConfigKey object, and call configKey.getDescription() etc.

     @SetFromFlag("bindAddress")
     BasicAttributeSensorAndConfigKey<String> BIND_ADDRESS =
             new StringAttributeSensorAndConfigKey("jboss.bind.address",
                 "Address of interface JBoss should listen on, 
defaulting 0.0.0.0 (but could set e.g. to attributeWhenReady(HOSTNAME)",
                 "0.0.0.0");

I suggest we use Reflections, and have a simple tool that will scan the 
classpath (either the current classpath, or optionally scan a given jar).

This will work for entities, policies, enrichers, etc.

---
That tool can spit out some intermediate format. For example, a YAML 
file giving the details.

We can then have a second tool that generates static HTML from a YAML 
input. In that way,the "simple classpath scanning tool" will not need to 
change much, e.g. when we're changing the html.

---
Medium/long term, we'll want to figure out what additional annotations 
(or fields of annotations) to add, for additional meta-data about each 
entity.

I suggest we add @Catalog annotations to pretty much every entity. That 
would be a good place to put a short description of the entity.

---
I plan to play around with a reflections-based scanner.

Thoughts?

Aled


On 12/08/2014 15:46, Andrew Kennedy wrote:
> I think we could probably re-purpose the Javadoc Doclet processor that
> enumerates information about everything implementing the Entity
> interface, and outputs the public static final ConfigKeys, Attributes
> and Effectors with their documentation as a series of HTML pages, one
> per entity.
>
> Andrew.
> --
> -- andrew kennedy ? cloud engineer : http://blog.abstractvisitorpattern.co.uk/ ;
>
>
> On 12 August 2014 12:39, Richard Downer <richard@apache.org> wrote:
>> Good idea. We are overdue with filling the website with content so
>> I've posted a proposal to kick-start a discussion about the website,
>> and included a space for a description of the core entities.
>>
>> Richard.
>>
>> On 8 August 2014 12:37, Duncan Johnston Watt
>> <duncan.johnstonwatt@cloudsoftcorp.com> wrote:
>>> Could we follow the jclouds provider model[1] and make sure that every
>>> entity supported in core brooklyn is listed on the site and also visible
>>> via catalog?
>>>
>>> For the latter I assume any entity will need to ship with stock
>>> blueprint(s). These can of course be improved with time too.
>>>
>>> [1] http://jclouds.apache.org/reference/providers/
>>>
>>> Best
>>> --
>>> Duncan Johnston-Watt
>>> CEO | Cloudsoft Corporation
>>>
>>> Twitter | @duncanjw
>>> Mobile | +44 777 190 2653
>>> Skype | duncan_johnstonwatt
>>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>>>
>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>>   Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>>
>>> This e-mail message is confidential and for use by the addressee only. If
>>> the message is received by anyone other than the addressee, please return
>>> the message to the sender by replying to it and then delete the message
>>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
>>> Corporation Limited does not accept responsibility for changes made to this
>>> message after it was sent.
>>>
>>> Whilst all reasonable care has been taken to avoid the transmission of
>>> viruses, it is the responsibility of the recipient to ensure that the
>>> onward transmission, opening or use of this message and any attachments
>>> will not adversely affect its systems or data. No responsibility is
>>> accepted by Cloudsoft Corporation Limited in this regard and the recipient
>>> should carry out such virus and other checks as it considers appropriate.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message