On Tue, Jun 25, 2013 at 6:16 PM, Bram de Kruijff <[email protected]> wrote: > Hi Wilfried! > > On Tue, Jun 25, 2013 at 5:30 PM, <[email protected]> wrote: >> Hi Marcel >> >> This was a good recommendation. I was able to implement a set of gogo >> commands to work on the ACE repo. >> >> One short question: >> Are the left- and rigthCardinality mandatory or optional attributes? >> I added some associations without any cardinality and they are all displayed >> correctly within the UI. >> >> Currently I don't really understand the principle of these attributes. >> Having 1:1 cardinality is clear. But is this evaluated somewhere in the code? >> Mostly I see the value 2147483647. This is the MAX_INT. But I think that >> this value is platform dependent and seems not to be a good choice. Or do I >> misunderstand this issue? >> > > Cardinality is optional and will default to one. For simple > associations where the filter always matches one candidate (eg. > name=foo) this is good enough. However, when you start using filters > that may match multiple candidates (eg. name=foo*) and you want an > one-to-many association the cardinality must be set to an appropriate > number. Indeed the default for many is MAX_INT with basically is meant > to express infinity. This if you have a filter that matches more the > MAX_INT candidates you just found a bug ;) > > @see ArtifactObjectImpl#locateEndpoint() >
correction.. @see AssociationImpl#locateEndpoint() > An example of using a filter that matches multiple candidates and then > using cardinality to choose is used for auto upgrading bundles. The > filter selects the candidates by symbolicname (symbolicname=foo), > sorts them using a version Comparator and then takes the first > (cardinality=1). This result in an association that always matches the > latest bundle. > > Hope this helps clarify the mechanism a little :) > > Best regards, > Bram > > >> Some information would be very appreciated. >> >> Regards >> Wilfried >> >> >> -----Ursprüngliche Nachricht----- >> Von: Marcel Offermans [mailto:[email protected]] >> Gesendet: Donnerstag, 20. Juni 2013 14:05 >> An: [email protected] >> Betreff: Re: ACE client >> >> On Jun 20, 2013, at 11:42 AM, <[email protected]> wrote: >> >>> But nevertheless, I will write a small bundle including the bndrun file and >>> use the bundle start method to test something... >> >> That works. If you want a bit more flexibility, you can write a shell >> command, by making an Activator that does something like this: >> >> public class Activator extends DependencyActivatorBase { >> @Override >> public void init(BundleContext context, DependencyManager manager) >> throws Exception { >> Properties props = new Properties(); >> props.put(CommandProcessor.COMMAND_SCOPE, "myscope"); >> props.put(CommandProcessor.COMMAND_FUNCTION, new String[] { "test", >> "two" }); >> manager.add(createComponent() >> .setInterface(Object.class.getName(), props) >> .setImplementation(Commands.class) >> ); >> } >> >> @Override >> public void destroy(BundleContext context, DependencyManager manager) >> throws Exception { >> } >> } >> >> and a Commands class with commands that do something like this: >> >> public class Commands { >> public void test() { >> System.out.println("test command executing"); >> } >> >> public void two() throws Exception { >> throw new RuntimeException("I throw an exception."); >> } >> } >> >> Of course your commands should do something useful, and you might want to >> inject certain service dependencies into that class, but this is the idea. >> From the shell you can then simply type: "test" (or "myscope:test" if there >> exists more than one "test" command in different scopes). >> >> Greetings, Marcel >>
