brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
Subject Re: Unexpected behaviour
Date Fri, 13 May 2016 13:51:56 GMT
Hi David,
That's probably related to a previous thread - http://mail-archives.apache.org/mod_mbox/brooklyn-dev/201604.mbox/%3CCADkof5ZX_pCP+YZzKd28gjfiJWLxCjMiiFWve0aYh2=4nxzULg@mail.gmail.com%3E
<http://mail-archives.apache.org/mod_mbox/brooklyn-dev/201604.mbox/%3CCADkof5ZX_pCP+YZzKd28gjfiJWLxCjMiiFWve0aYh2=4nxzULg@mail.gmail.com%3E>

When resolving resources the catalog item in the current context is used, its libraries in
particular. Currently Brooklyn automatically populates its catalog from the entities on the
classpath which means that there's a java entity called org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
and a catalog item with the same id. Catalog items take precedence over java entities when
resolving the yaml. 
What happens is that when resolving your yaml, "org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess"
will point to the Brooklyn provided catalog item which doesn't have any libraries defined,
so loading resources will fail.
When you use the old package name "brooklyn.entity.basic.VanillaSoftwareProcess" there's no
catalog item with the same name, so it's resolved directly to the java entity, so the catalog
item context doesn't change and you can still use your libraries.

To work around it add a "java:" prefix to the entity names. This will skip loading catalog
items and go straight to the java entity.

The current behaviour is not really user friendly so we need to find a better way at resolving
the resources, but at least the workaround is easy to apply for the time being.

Svet.


> On 12.05.2016 г., at 14:32, David Bush <david.bush@cloudsoftcorp.com> wrote:
> 
> Hi,
> 
> Hopefully this carries enough explanation - please ask if not.  
> 
> I have found a difference in behaviour between org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
and brooklyn.entity.basic.VanillaSoftwareProcess which was not expected.
> 
> Using the first prefix I am unable to resolve resources from the classpath, whereas with
the second prefix I can (examples below).
> 
> I understood that these should be equivalent and that under the covers a mapping is made
from the old to new versions?
> 
> Is this unexpected?  
> 
> Nonworking example (no difference if SameServerEntity is basic or apache):
> 
>>> brooklyn.catalog:
>>>  items:
>>>  - id: vc-node
>>>    itemType: template
>>>    item:
>>>      services:
>>>      - type: brooklyn.entity.basic.SameServerEntity
>>>        brooklyn.children:
>>>        - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
>>>          id: consul
>>>          name: consul
> 
> Working example:
> 
> brooklyn.catalog:
>  items:
>  - id: vc-node
>    itemType: template
>    item:
>      services:
>      - type: brooklyn.entity.basic.SameServerEntity
>        brooklyn.children:
>        - type: brooklyn.entity.basic.VanillaSoftwareProcess
>          id: consul
>          name: consul
> 
> -- 
> David Bush • Systems Integrator • Cloudsoft Corporation • http://www.cloudsoftcorp.com
<http://www.cloudsoftcorp.com/>
> T: 07834 127195 • SKYPE: david.c.bush
> 


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