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() 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 >
