You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ace.apache.org by Wi...@bosch-si.com on 2013/06/20 10:57:31 UTC
ACE client
Hi to all
I want to play a little bit around with the JAVA client API (and of course with its implementation).
Is there a way to test the API without an OSGi container?
It would be nice to start with writing a simple JUnit test case etc.
But I assume, that this isn't possible that simple.
Does anyone has a recommendation for this "play case"??
Regards
Wilfried
AW: ACE client
Posted by Wi...@bosch-si.com.
Hi
Thx to you and Bram for the explanations. Now I would say, that I understand cardinality. Cardinality in general was already clear, but in conjunction with the ACE implementation, it wasn't.
Now I got it.
Regards
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Dienstag, 25. Juni 2013 23:33
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
You're welcome!
> One short question:
> Are the left- and rigthCardinality mandatory or optional attributes?
It is mandatory, because we need to know what you want.
> I added some associations without any cardinality and they are all displayed correctly within the UI.
If you don't specify them, 1:1 is assumed.
> 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?
Let me start by stating that in Java, data types and their limits are defined in a platform independent way. So Integer.MAX_VALUE is the same everywhere.
Now, to explain cardinality and how it cooperates with filter conditions. Let's start with filters. You can specify a filter that might match more than one instance. Whenever that happens, you end up with a collection of instances. Now, the first thing that happens is that this collection gets sorted. How? With a comparator that you can specify per instance (or, for example for artifacts, which can have many types, per type). After the collection is sorted, the cardinality is used to determine how many instances to keep in the collection (in most cases either 1 or everything).
Let's use a bundle as an example:
1) You have a filter that states: (Bundle-SymbolicName=org.foo.util) and this matches for example two entities: org.foo.util version 1.0 and version 1.1.
2) Then the list gets sorted: the highest version ends up on top.
3) Then, if cardinality is 1, only the highest one will end up being selected.
As you can see, this is a way to say: give me the highest version of bundle org.foo.util.
You could also, in the spirit of semantic versioning, say that you want the highest version in the range from [1.0, 2.0) by having a filter that states: (&(Bundle-SymbolicName=org.foo.util)(Bundle-Version>=1.0)(Bundle-Version<2.0))
Greetings, Marcel
AW: Gogo commands
Posted by Wi...@bosch-si.com.
Hi Marcel
Thx a lot. I already got it....
Danke und Grüße
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Montag, 1. Juli 2013 16:51
An: users@ace.apache.org
Betreff: Re: Gogo commands
On Jul 1, 2013, at 15:18 , Wilfried.Sibla@bosch-si.com wrote:
> A short question to your suggestion (there's quite enough still have to learn):
> You wrote on the wiki (https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API), that only the two command cw (create workspace) and rw (remove workspace) are real shell commands. And the others only operate on the created workspace.
Correct.
> Does the cf command return a workspace object?
Yes, that's what happens when I say:
w = (cw)
> And are the following commands like $w la (list artifacts) methods of the Workspace class.
Yes, methods that are invoked on the object that cw returned, and that was stored in the variable called w, so:
$w foo a b
literally invokes a method "foo" on the instance w, and tries to actually find a method that has two parameters a and b.
> Or how does this work?
> Can you give me a hint, where I could read a bit more about this topic?
Yes:
http://felix.apache.org/documentation/subprojects/apache-felix-gogo.html
http://felix.apache.org/site/rfc-147-overview.html
http://www.osgi.org/download/osgi-4.2-early-draft.pdf
Admitted, the documentation is a bit all over the place. :) On the positive side, not only Felix is using the GoGo shell, but also more recently Equinox, so if you Google a bit you usually find some more tutorials. Many things have also been discussed on the Felix mailing lists, so searching the archives might also help.
Greetings, Marcel
Re: Gogo commands
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jul 1, 2013, at 15:18 , Wilfried.Sibla@bosch-si.com wrote:
> A short question to your suggestion (there's quite enough still have to learn):
> You wrote on the wiki (https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API), that only the two command cw (create workspace) and rw (remove workspace) are real shell commands. And the others only operate on the created workspace.
Correct.
> Does the cf command return a workspace object?
Yes, that's what happens when I say:
w = (cw)
> And are the following commands like $w la (list artifacts) methods of the Workspace class.
Yes, methods that are invoked on the object that cw returned, and that was stored in the variable called w, so:
$w foo a b
literally invokes a method "foo" on the instance w, and tries to actually find a method that has two parameters a and b.
> Or how does this work?
> Can you give me a hint, where I could read a bit more about this topic?
Yes:
http://felix.apache.org/documentation/subprojects/apache-felix-gogo.html
http://felix.apache.org/site/rfc-147-overview.html
http://www.osgi.org/download/osgi-4.2-early-draft.pdf
Admitted, the documentation is a bit all over the place. :) On the positive side, not only Felix is using the GoGo shell, but also more recently Equinox, so if you Google a bit you usually find some more tutorials. Many things have also been discussed on the Felix mailing lists, so searching the archives might also help.
Greetings, Marcel
Gogo commands
Posted by Wi...@bosch-si.com.
Hi Marcel
A short question to your suggestion (there's quite enough still have to learn):
You wrote on the wiki (https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API), that only the two command cw (create workspace) and rw (remove workspace) are real shell commands. And the others only operate on the created workspace.
Does the cf command return a workspace object? And are the following commands like $w la (list artifacts) methods of the Workspace class.
Or how does this work?
Can you give me a hint, where I could read a bit more about this topic?
Thx
Greetings
Wilfried
-----Ursprüngliche Nachricht-----
Von: Wilfried.Sibla@bosch-si.com [mailto:Wilfried.Sibla@bosch-si.com]
Gesendet: Mittwoch, 26. Juni 2013 10:24
An: users@ace.apache.org
Betreff: AW: ACE client
Hi Marcel
With the discussed gogo commands I tried to learn how to use the ACE client java API.
For implementing our own customized ACE client (containing integration code for out other services) is it recommended to use the plain java API or to "use" the REST ACE client?
Starting with using the java API worked quite good for my first steps.
If I would like to use the REST client, or at least the Workspace class, I would have setup my one project(s) similar to the REST client. It would be nearly a copy of the REST client, which I have to customize and extend to fit our needs.
Or what's your recommendation?
Danke und Grüße
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Mittwoch, 26. Juni 2013 01:33
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 25, 2013, at 23:33 PM, Marcel Offermans <ma...@luminis.nl> wrote:
> On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
>
>> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
>
> You're welcome!
Following up on this, I just created https://issues.apache.org/jira/browse/ACE-366 and added a first implementation of a set of shell commands. I also created a wiki page with some short documentation about it: https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API
I'm curious if this is similar to the shell commands you created and what you think about it. I'm quite confident that the shell is a powerful way to script ACE.
Greetings, Marcel
AW: ACE client
Posted by Wi...@bosch-si.com.
Hi Marcel
Greetings
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Mittwoch, 26. Juni 2013 13:22
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 26, 2013, at 10:24 AM, <Wi...@bosch-si.com> wrote:
> With the discussed gogo commands I tried to learn how to use the ACE client java API.
> For implementing our own customized ACE client (containing integration code for out other services) is it recommended to use the plain java API or to "use" the REST ACE client?
I would recommend using the plain Java API in this case as it is a faster way if you want to do lots of manipulations (direct method calls vs HTTP calls).
[Wilfried Sibla] I meant, implementing my own REST client, but "deriving" it from the existing REST client. Not using the existing REST client from my REST client....
With your last mail I also understand that the VaadinClient itself is the workspace.
> Starting with using the java API worked quite good for my first steps.
Ok.
> If I would like to use the REST client, or at least the Workspace class, I would have setup my one project(s) similar to the REST client. It would be nearly a copy of the REST client, which I have to customize and extend to fit our needs.
> Or what's your recommendation?
If you want to build your own, customized REST client on top of the client Java API, that is definitely something you can do. I would then recommend to make those commands somewhat more "high level" so you don't end up making 10 HTTP requests to add an artifact, link it to a feature and distribution, etc. For building the actual REST client, I would recommend looking at the Amdatu Web components [1] that have support for JAX-RS and make it a lot easier implementing REST endpoints. We intend to do that for the REST endpoints already in ACE too [2].
[Wilfried Sibla] That's my intention. I have to build such customized REST client. Using the Amdatu Web components is very probably. My colleagues are often using Jersey as a REST-WS framework. I will take a look what helps me more and will decide.
Greetings, Marcel
[1] http://amdatu.org/components/web.html
[2] https://issues.apache.org/jira/browse/ACE-326
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 26, 2013, at 10:24 AM, <Wi...@bosch-si.com> wrote:
> With the discussed gogo commands I tried to learn how to use the ACE client java API.
> For implementing our own customized ACE client (containing integration code for out other services) is it recommended to use the plain java API or to "use" the REST ACE client?
I would recommend using the plain Java API in this case as it is a faster way if you want to do lots of manipulations (direct method calls vs HTTP calls).
> Starting with using the java API worked quite good for my first steps.
Ok.
> If I would like to use the REST client, or at least the Workspace class, I would have setup my one project(s) similar to the REST client. It would be nearly a copy of the REST client, which I have to customize and extend to fit our needs.
> Or what's your recommendation?
If you want to build your own, customized REST client on top of the client Java API, that is definitely something you can do. I would then recommend to make those commands somewhat more "high level" so you don't end up making 10 HTTP requests to add an artifact, link it to a feature and distribution, etc. For building the actual REST client, I would recommend looking at the Amdatu Web components [1] that have support for JAX-RS and make it a lot easier implementing REST endpoints. We intend to do that for the REST endpoints already in ACE too [2].
Greetings, Marcel
[1] http://amdatu.org/components/web.html
[2] https://issues.apache.org/jira/browse/ACE-326
AW: ACE client
Posted by Wi...@bosch-si.com.
Hi Marcel
With the discussed gogo commands I tried to learn how to use the ACE client java API.
For implementing our own customized ACE client (containing integration code for out other services) is it recommended to use the plain java API or to "use" the REST ACE client?
Starting with using the java API worked quite good for my first steps.
If I would like to use the REST client, or at least the Workspace class, I would have setup my one project(s) similar to the REST client. It would be nearly a copy of the REST client, which I have to customize and extend to fit our needs.
Or what's your recommendation?
Danke und Grüße
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Mittwoch, 26. Juni 2013 01:33
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 25, 2013, at 23:33 PM, Marcel Offermans <ma...@luminis.nl> wrote:
> On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
>
>> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
>
> You're welcome!
Following up on this, I just created https://issues.apache.org/jira/browse/ACE-366 and added a first implementation of a set of shell commands. I also created a wiki page with some short documentation about it: https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API
I'm curious if this is similar to the shell commands you created and what you think about it. I'm quite confident that the shell is a powerful way to script ACE.
Greetings, Marcel
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Wilfried,
On Jun 26, 2013, at 9:58 AM, <Wi...@bosch-si.com> wrote:
> I just flew over your Wiki page. This looks good.
> I had a slightly different, more generic, approach.
> I implemented e.g. the command: add feature name=foo .... list of attributes
> For this approach, less dedicated commands are necessary. But nevertheless, it's a trade of. A change would be very easy.
Yes, I considered both and in the end went for individual commands because then I could make them a bit shorter to type. :) But I agree there's not much difference.
> What's your opinion about this?
> But I'm also fine with your proposal.
I don't have strong arguments for either, and as you can see from the implementations, some specific commands I have call more generic methods in the backend. Coupled with the fact that you can also create your own aliases in the shell, I see a command like "cf" more like a "built in alias" ;)
> As a starting point I used the VaadinClient and derived my own client from that.
> But the VaadinClient doesn't use a workspace. The REST client does.
In the VaadinClient, the workspace is implicit (it is the VaadinClient). From the web UI you always work with a single workspace. From that point on, they are again the same (you login, checkout, talk to the services to manipulate entities and then commit).
> I implemented directly the login command (delegated to the login of the client API) and used also the checkout.
> This worked (nearly) fine in my tests.
Yup, that's the general idea.
> I have to investigate a little bit on the REsT workspace, to understand this topic a little bit better.
> Then I will switch over to it.
I used the REST Workspace because I thought it would be slightly more convenient as a starting point. At this point, I feel the commands are still very much in an experimental phase. We are starting to use them and learn what works and what not, so please keep providing feedback!
Greetings, Marcel
AW: ACE client
Posted by Wi...@bosch-si.com.
Hi Marcel
I just flew over your Wiki page. This looks good.
I had a slightly different, more generic, approach.
I implemented e.g. the command: add feature name=foo .... list of attributes
For this approach, less dedicated commands are necessary. But nevertheless, it's a trade of. A change would be very easy.
What's your opinion about this?
But I'm also fine with your proposal.
As a starting point I used the VaadinClient and derived my own client from that.
But the VaadinClient doesn't use a workspace. The REST client does.
I implemented directly the login command (delegated to the login of the client API) and used also the checkout.
This worked (nearly) fine in my tests.
I have to investigate a little bit on the REsT workspace, to understand this topic a little bit better.
Then I will switch over to it.
Danke und Grüße
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Mittwoch, 26. Juni 2013 01:33
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 25, 2013, at 23:33 PM, Marcel Offermans <ma...@luminis.nl> wrote:
> On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
>
>> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
>
> You're welcome!
Following up on this, I just created https://issues.apache.org/jira/browse/ACE-366 and added a first implementation of a set of shell commands. I also created a wiki page with some short documentation about it: https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API
I'm curious if this is similar to the shell commands you created and what you think about it. I'm quite confident that the shell is a powerful way to script ACE.
Greetings, Marcel
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 25, 2013, at 23:33 PM, Marcel Offermans <ma...@luminis.nl> wrote:
> On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
>
>> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
>
> You're welcome!
Following up on this, I just created https://issues.apache.org/jira/browse/ACE-366 and added a first implementation of a set of shell commands. I also created a wiki page with some short documentation about it: https://cwiki.apache.org/confluence/display/ACE/Gogo+Shell+client+API
I'm curious if this is similar to the shell commands you created and what you think about it. I'm quite confident that the shell is a powerful way to script ACE.
Greetings, Marcel
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 25, 2013, at 17:30 , Wilfried.Sibla@bosch-si.com wrote:
> This was a good recommendation. I was able to implement a set of gogo commands to work on the ACE repo.
You're welcome!
> One short question:
> Are the left- and rigthCardinality mandatory or optional attributes?
It is mandatory, because we need to know what you want.
> I added some associations without any cardinality and they are all displayed correctly within the UI.
If you don't specify them, 1:1 is assumed.
> 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?
Let me start by stating that in Java, data types and their limits are defined in a platform independent way. So Integer.MAX_VALUE is the same everywhere.
Now, to explain cardinality and how it cooperates with filter conditions. Let's start with filters. You can specify a filter that might match more than one instance. Whenever that happens, you end up with a collection of instances. Now, the first thing that happens is that this collection gets sorted. How? With a comparator that you can specify per instance (or, for example for artifacts, which can have many types, per type). After the collection is sorted, the cardinality is used to determine how many instances to keep in the collection (in most cases either 1 or everything).
Let's use a bundle as an example:
1) You have a filter that states: (Bundle-SymbolicName=org.foo.util) and this matches for example two entities: org.foo.util version 1.0 and version 1.1.
2) Then the list gets sorted: the highest version ends up on top.
3) Then, if cardinality is 1, only the highest one will end up being selected.
As you can see, this is a way to say: give me the highest version of bundle org.foo.util.
You could also, in the spirit of semantic versioning, say that you want the highest version in the range from [1.0, 2.0) by having a filter that states: (&(Bundle-SymbolicName=org.foo.util)(Bundle-Version>=1.0)(Bundle-Version<2.0))
Greetings, Marcel
Re: ACE client
Posted by Bram de Kruijff <bd...@gmail.com>.
On Tue, Jun 25, 2013 at 6:16 PM, Bram de Kruijff <bd...@gmail.com> wrote:
> Hi Wilfried!
>
> On Tue, Jun 25, 2013 at 5:30 PM, <Wi...@bosch-si.com> 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:marcel.offermans@luminis.nl]
>> Gesendet: Donnerstag, 20. Juni 2013 14:05
>> An: users@ace.apache.org
>> Betreff: Re: ACE client
>>
>> On Jun 20, 2013, at 11:42 AM, <Wi...@bosch-si.com> 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
>>
Re: ACE client
Posted by Bram de Kruijff <bd...@gmail.com>.
Hi Wilfried!
On Tue, Jun 25, 2013 at 5:30 PM, <Wi...@bosch-si.com> 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:marcel.offermans@luminis.nl]
> Gesendet: Donnerstag, 20. Juni 2013 14:05
> An: users@ace.apache.org
> Betreff: Re: ACE client
>
> On Jun 20, 2013, at 11:42 AM, <Wi...@bosch-si.com> 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
>
AW: ACE client
Posted by Wi...@bosch-si.com.
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?
Some information would be very appreciated.
Regards
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Donnerstag, 20. Juni 2013 14:05
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 20, 2013, at 11:42 AM, <Wi...@bosch-si.com> 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
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
No problem Ryan! :)
On Jun 20, 2013, at 14:39 PM, Ryan Moquin <fr...@gmail.com> wrote:
> Sorry my bad, I was intending my response for the author of the thread, I
> just hit reply to your so it looked like I was saying it to you but that
> wasn't intended. I figured you would have int tests for ACE :) I should
> have hit reply to the initial message.
>
> Ryan
>
> Ryan
> On Jun 20, 2013 8:33 AM, "Marcel Offermans" <ma...@luminis.nl>
> wrote:
>
>> Hello Ryan,
>>
>> On Jun 20, 2013, at 14:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
>>
>>> Why not take a look at the karaf project documentation, it tells you how
>> to
>>> setup an integration test, it's really not hard at all and the
>>> documentation is pretty accurate. If you go to karaf.apache.org, under
>>> developer guide documentation there is an integrarion test section, it
>> does
>>> a good job explaining things.
>>
>> We already have integration tests, that's not the point (just look at any
>> of the projects in ACE that end with ".itest").
>>
>> Greetings, Marcel
>>
>>
Re: ACE client
Posted by Ryan Moquin <fr...@gmail.com>.
Sorry my bad, I was intending my response for the author of the thread, I
just hit reply to your so it looked like I was saying it to you but that
wasn't intended. I figured you would have int tests for ACE :) I should
have hit reply to the initial message.
Ryan
Ryan
On Jun 20, 2013 8:33 AM, "Marcel Offermans" <ma...@luminis.nl>
wrote:
> Hello Ryan,
>
> On Jun 20, 2013, at 14:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
>
> > Why not take a look at the karaf project documentation, it tells you how
> to
> > setup an integration test, it's really not hard at all and the
> > documentation is pretty accurate. If you go to karaf.apache.org, under
> > developer guide documentation there is an integrarion test section, it
> does
> > a good job explaining things.
>
> We already have integration tests, that's not the point (just look at any
> of the projects in ACE that end with ".itest").
>
> Greetings, Marcel
>
>
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Ryan,
On Jun 20, 2013, at 14:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
> Why not take a look at the karaf project documentation, it tells you how to
> setup an integration test, it's really not hard at all and the
> documentation is pretty accurate. If you go to karaf.apache.org, under
> developer guide documentation there is an integrarion test section, it does
> a good job explaining things.
We already have integration tests, that's not the point (just look at any of the projects in ACE that end with ".itest").
Greetings, Marcel
Re: ACE client
Posted by Ryan Moquin <fr...@gmail.com>.
Why not take a look at the karaf project documentation, it tells you how to
setup an integration test, it's really not hard at all and the
documentation is pretty accurate. If you go to karaf.apache.org, under
developer guide documentation there is an integrarion test section, it does
a good job explaining things.
If you need any help, the guys on the karaf user list are always willing to
answer any questions and point to examples.
Ryan
On Jun 20, 2013 8:05 AM, "Marcel Offermans" <ma...@luminis.nl>
wrote:
> On Jun 20, 2013, at 11:42 AM, <Wi...@bosch-si.com> 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
>
>
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 20, 2013, at 11:42 AM, <Wi...@bosch-si.com> 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
AW: ACE client
Posted by Wi...@bosch-si.com.
Thx a lot
I run the server-allinone as a server having the repos etc.
Implementing a small bundle, using the client API and service is ok.
But executing a certain operation is not as easy as using a JUnit test case.
But nevertheless, I will write a small bundle including the bndrun file and use the bundle start method to test something...
Regards
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Donnerstag, 20. Juni 2013 11:26
An: users@ace.apache.org
Betreff: Re: ACE client
Hello Wilfried,
On Jun 20, 2013, at 10:57 AM, <Wi...@bosch-si.com> wrote:
> I want to play a little bit around with the JAVA client API (and of course with its implementation).
>
> Is there a way to test the API without an OSGi container?
Currently, no. The API is basically a set of OSGi services, so you need to be in a container to talk to it. That is also how the Web UI and REST client API are built on top of the client API.
> It would be nice to start with writing a simple JUnit test case etc.
> But I assume, that this isn't possible that simple.
It would always be an "integration test" because you need both the client API and a server running somewhere (to checkout from and commit to). You could indeed, as Karl suggests, try to use the "all in one" server with PojoSR if you really want to run it outside of an OSGi container, but you might as well just setup an integration test then.
> Does anyone has a recommendation for this "play case"??
I would just write a bundle that talks to the client API, and run all of that in Eclipse with Bndtools. Then you can just write code and immediately test it.
Another option, in the future, would be to leverage the GoGo shell and write scripts for that. I'm currently toying around with that on my local machine, but I intend to commit that work soon. What you can do yourself is also write your test code as one or more shell commands, so you can quickly and interactively run such code from the shell.
Greetings, Marcel
AW: ACE client
Posted by Wi...@bosch-si.com.
Thx Marcel
I already figured it out the the client is the vaadin client UI.
Got it to run as separate "modules"
Regards
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Donnerstag, 20. Juni 2013 13:10
An: users@ace.apache.org
Betreff: Re: ACE client
On Jun 20, 2013, at 13:04 PM, <Wi...@bosch-si.com> wrote:
> What is the purpose of the project run-client?
> Is this the run project providing the REST client?
Logically, the ACE architecture defines four nodes with different responsibilities:
1) The OBR, a repository that holds all artifacts and makes them accessible via a URL.
2) The server, which holds all meta-data and is the central point where targets and clients connect to.
3) The client, which is responsible for manipulating the meta-data (via Web UI, REST or any other client you create).
4) The target, with management agent, which is where the artifacts get deployed to.
For each we have a "run-" project, but since you often quickly want to run server, OBR and client, we also have a "server-allinone" that is a combination of the three.
So, you can either run "server-allinone" (and a target), or run "server", "client" and "OBR" (and a target).
Greetings, Marcel
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 20, 2013, at 13:04 PM, <Wi...@bosch-si.com> wrote:
> What is the purpose of the project run-client?
> Is this the run project providing the REST client?
Logically, the ACE architecture defines four nodes with different responsibilities:
1) The OBR, a repository that holds all artifacts and makes them accessible via a URL.
2) The server, which holds all meta-data and is the central point where targets and clients connect to.
3) The client, which is responsible for manipulating the meta-data (via Web UI, REST or any other client you create).
4) The target, with management agent, which is where the artifacts get deployed to.
For each we have a "run-" project, but since you often quickly want to run server, OBR and client, we also have a "server-allinone" that is a combination of the three.
So, you can either run "server-allinone" (and a target), or run "server", "client" and "OBR" (and a target).
Greetings, Marcel
AW: ACE client
Posted by Wi...@bosch-si.com.
Hello again
What is the purpose of the project run-client?
Is this the run project providing the REST client?
Regards
Wilfried
-----Ursprüngliche Nachricht-----
Von: Marcel Offermans [mailto:marcel.offermans@luminis.nl]
Gesendet: Donnerstag, 20. Juni 2013 11:26
An: users@ace.apache.org
Betreff: Re: ACE client
Hello Wilfried,
On Jun 20, 2013, at 10:57 AM, <Wi...@bosch-si.com> wrote:
> I want to play a little bit around with the JAVA client API (and of course with its implementation).
>
> Is there a way to test the API without an OSGi container?
Currently, no. The API is basically a set of OSGi services, so you need to be in a container to talk to it. That is also how the Web UI and REST client API are built on top of the client API.
> It would be nice to start with writing a simple JUnit test case etc.
> But I assume, that this isn't possible that simple.
It would always be an "integration test" because you need both the client API and a server running somewhere (to checkout from and commit to). You could indeed, as Karl suggests, try to use the "all in one" server with PojoSR if you really want to run it outside of an OSGi container, but you might as well just setup an integration test then.
> Does anyone has a recommendation for this "play case"??
I would just write a bundle that talks to the client API, and run all of that in Eclipse with Bndtools. Then you can just write code and immediately test it.
Another option, in the future, would be to leverage the GoGo shell and write scripts for that. I'm currently toying around with that on my local machine, but I intend to commit that work soon. What you can do yourself is also write your test code as one or more shell commands, so you can quickly and interactively run such code from the shell.
Greetings, Marcel
Re: ACE client
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Wilfried,
On Jun 20, 2013, at 10:57 AM, <Wi...@bosch-si.com> wrote:
> I want to play a little bit around with the JAVA client API (and of course with its implementation).
>
> Is there a way to test the API without an OSGi container?
Currently, no. The API is basically a set of OSGi services, so you need to be in a container to talk to it. That is also how the Web UI and REST client API are built on top of the client API.
> It would be nice to start with writing a simple JUnit test case etc.
> But I assume, that this isn't possible that simple.
It would always be an "integration test" because you need both the client API and a server running somewhere (to checkout from and commit to). You could indeed, as Karl suggests, try to use the "all in one" server with PojoSR if you really want to run it outside of an OSGi container, but you might as well just setup an integration test then.
> Does anyone has a recommendation for this "play case"??
I would just write a bundle that talks to the client API, and run all of that in Eclipse with Bndtools. Then you can just write code and immediately test it.
Another option, in the future, would be to leverage the GoGo shell and write scripts for that. I'm currently toying around with that on my local machine, but I intend to commit that work soon. What you can do yourself is also write your test code as one or more shell commands, so you can quickly and interactively run such code from the shell.
Greetings, Marcel
Re: ACE client
Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Jun 20, 2013 at 10:57 AM, <Wi...@bosch-si.com> wrote:
> Hi to all
>
> I want to play a little bit around with the JAVA client API (and of course
> with its implementation).
>
> Is there a way to test the API without an OSGi container?
> It would be nice to start with writing a simple JUnit test case etc.
> But I assume, that this isn't possible that simple.
>
> Does anyone has a recommendation for this "play case"??
>
You could try pojosr: http://pojosr.googlecode.com
regards,
Karl
> Regards
> Wilfried
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls