You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Gerald Bortis <ge...@webreachinc.com> on 2009/02/04 04:58:44 UTC
Making sense of service binding and dependencies
Hi all,
I've been playing with OSGi and Felix for the past week, and I think I have
a general understanding of how to apply it to my application. So far, I've
refactored my code into bundle-friendly packages and have setup a build
system to generate my bundles. For every bundle, I have the following
pattern:
FooActivator.java
FooService.java
FooServiceImpl.java
FooActivator implements BundleActivator, and in the start method registers
FooService. Pretty straightforward. The issues I've run into are the
following:
a) What is the best way to call BarService from FooServiceImpl? I've tried
both the ServiceTracker pattern, and the ServiceBinding-Utils, but both seem
a bit convoluted.
b) What is the best way to make sure that FooServiceImpl doesn't call
BarService before BarService has been reigstered?
For the second issue, I thought I was on the right path when I found the
Depedency Manager bundle, but the example isn't clear how registering a
ServiceDepedency on BarService instantiates the instance that FooServiceImpl
requires? This lead me to the iPOJO section, which promises to address these
issues, but I'm not sure if it's what I'm looking for either. Does using
Dependency Manager or iPOJOs also address my first issue of how to implicity
bind the services? Any pointers in the right direction are appreciated.
Regards,
Gerald
Re: Making sense of service binding and dependencies
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
> b) What is the best way to make sure that FooServiceImpl doesn't call
> BarService before BarService has been reigstered?
>
> For the second issue, I thought I was on the right path when I found the
> Depedency Manager bundle, but the example isn't clear how registering a
> ServiceDepedency on BarService instantiates the instance that FooServiceImpl
> requires?
The global purpose of all injections framework is just that: to ensure
that you won't start working before your dependencies are there.
You may think of it as a generalization of the constructor pattern.
To implement this, frameworks often require you to have an empty
constructor (meaning no arguments) and to implement a "start" method.
The framework then starts listening for the dependencies you specified.
When all required dependencies are resolved (found in the service
registry), the framework will instantiate your component, give it its
dependencies (via binding methods or direct field injection) and finally
call you on your start method, where you know that everything has arrived.
If no dependency is specified the service is instantiated right away.
As soon as a service is started it is made available for others via the
service registry.
All framework relying on the underlying service registry, they can co-exist
(some bundles using DeclarativeService, others using DependencyManager...)
DependencyManager does this very well in a lightweight, understandable
and fully customizable manner, even supporting non-empty service
constructors (if ever needed)
We design a platform with over a hundred services and as far as we're
concerned DependencyManager has addressed all our needs and beyond.
A simple example:
public class BarActivator extends DependencyActivatorBase {
public void init(BundleContext ctx, DependencyManager mgr) throws
Exception {
//BarImplementation doesn't have any dependencies, it is provided
right away
mgr.add(createService()
.setInterface(BarService.class.getName(), new Hashtable() {{
put("property", "value");
}})
.setImplementation(BarImplementation.class); //parameter can also be
a preconstructed object instance if needed
}
}
public class FooActivator extends DependencyActivatorBase {
public void init(BundleContext ctx, DependencyManager mgr) throws
Exception {
mgr.add(createService()
.setInterface(FooService.class.getName(), null)
.setImplementation(FooImplementation.class);
.add(createServiceDependency()
.setService(BarService.class, "(property=value)")
.setRequired(true)
));
}
/** note that FooImplementation is perfectly clean of any dependency on
the injection framework! */
public class FooImplementation implements FooService {
BarService _bs; //field is directly injected by DependencyManager
before calling start()
protected void start() {
System.out.println("starting with BarService="+_bs);
}
}
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Marcel Offermans <ma...@luminis.nl>.
On Feb 4, 2009, at 23:09 , Trejkaz wrote:
> I'll have my little complaint though. Fluent doesn't just mean it's
> Java, it means when you read it out loud it almost sounds like
> English. As such you'll notice that fluent APIs don't tend to use the
> word "set" in the method names.
Agreed, the names are not consistent with a fluent API, only the
method chaining part is. I'm a bit hesitant to change the names though
because the DM has been in use for years so I don't want to break
compatibility. Of course I could consider just adding new method names
instead, but to be honest I don't think that outweighs the
disadvantage of having two methods that do the same thing.
> But the examples posted in this thread thus far, I would not fit into
> the fluent category. They're more like a classical builder API. Not
> that there's anything wrong with that, I just don't want to see people
> start abusing terminology and then (slippery slope) 2 years down the
> track the entire JRE is considered to be a fluent API.
Ok. :)
Greetings, Marcel
Re: Making sense of service binding and dependencies
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/5 Trejkaz <tr...@trypticon.org>
> > public class Activator extends DependencyActivatorBase {
> > public void init(BundleContext c, DependencyManager m) {
> > m.add(createService()
> > .setInterface(FooService.class.getName(), null)
> > .setImplementation(FooServiceImpl.class)
> > .add
> > (createServiceDependency().setClass(BarService.class).setRequired(true))
> > );
> > }
> > }
>
> I think I'll hold off on using iPOJO heavily until this is possible,
> because it's great! I've never been a huge fan of XML because people
> seem to throw it around and try to pretend that it isn't API (Spring
> is one of the greatest offenders here.) In reality it is just more
> API, but which forces you to write your program in two languages. The
> Java equivalent is even more compact than the XML, and Java is already
> pretty verbose!
>
> I'll have my little complaint though. Fluent doesn't just mean it's
> Java, it means when you read it out loud it almost sounds like
> English. As such you'll notice that fluent APIs don't tend to use the
> word "set" in the method names.
>
> e.g. this is fluent:
>
> assertThat(m, isEqualTo(n));
>
> And this is fluent:
>
> m.add(new Service() {{
> withInterface(FooService.class.getName(),
> null).andImplementation(FooServiceImpl.class);
> withDependencyOn(BarService.class).required();
> withependencyOn(BazService.class, "(name=something)").temporal();
> }});
>
> But the examples posted in this thread thus far, I would not fit into
> the fluent category. They're more like a classical builder API. Not
> that there's anything wrong with that, I just don't want to see people
> start abusing terminology and then (slippery slope) 2 years down the
> track the entire JRE is considered to be a fluent API.
>
just curious, would you say this is fluent?
http://code.google.com/p/peaberry/wiki/UserGuide
(apologies for interrupting the DI dueling...)
TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Making sense of service binding and dependencies
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
> Beauty is in the eye of the beholder. :-)
Indeed :-)
> Byte code manipulation has nothing to do with annotations or vice
> versa. You can also manipulate based on XML, which we do from our XML
> as well in iPOJO.
Very true.
The remarks concerned bytecode manipulation ingeneral more than
annotations as such.
Now Clement also corrected me on these, so i guess it will require some
new testing on my side :-)
Altogether, I'm pleased to see that IPOJO is on the way to provide an
API based approach. I already glanced at the javadoc, I shall give it a try.
Thanks for all the valuable input.
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Arjun Panday wrote:
> Annotations is another form of API that the "POJO" directly depends
> upon. Annotations not being a JDK level standard, each container has
> its own set.
I agree, however...
> Annotations also make the code very difficult to read since the
> service dependencies are spread out all over the code.
This is precisely the opposite argument that proponents of annotations
make...the claim being annotations are better because they put the
information nearer to the thing to which it pertains.
Beauty is in the eye of the beholder. :-)
> Additional issues encountered with annotations used at runtime for
> bytecode manipulations are:
> - only one container is allowed to manipulate the bytecode: if two
> different containers rely on annotations at runtime (say one for OSGi
> and one for persistence for instance), they conflict.
> - bytecode manipulations (even offline) make the code very difficult
> to debug since the resulting code can be quite different from the
> originally written code (not to mention that the stack traces usually
> don't match anything anymore)
Byte code manipulation has nothing to do with annotations or vice versa.
You can also manipulate based on XML, which we do from our XML as well
in iPOJO.
-> richard
>
> Arjun
>
>
>
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Clement Escoffier <cl...@gmail.com>.
On 05.02.2009, at 10:34, Arjun Panday wrote:
> Marcel Offermans wrote:
>> On Feb 5, 2009, at 2:14 , Richard S. Hall wrote:
>>
>>>> Plus there is probably an argument somewhere that if you put the
>>>> annotations into the actual code, then that code can't be used
>>>> without
>>>> the ipojo.annotations jar lying around somewhere.
>>>>
>>>
>>> Certainly wouldn't be able to compile without them, but the API-
>>> based
>>> approach creates even a stronger dependency, so this really isn't an
>>> issue when comparing the two approaches I don't think. You can
>>> only get
>>> no API dependencies if you use XML.
>>
>> Well yes and no. Yes, the API based approach creates a strong
>> dependency within the BundleActivator. No, there is no API at all
>> in the actual POJO. So reusing the POJO becomes easy, only the
>> Activator is actually container specific.
> Agreed.
> Annotations is another form of API that the "POJO" directly depends
> upon. Annotations not being a JDK level standard, each container has
> its own set. The Activator on the other hand is by definition OSGi
> specific; its very goal is to interact with the framework.
> Annotations also make the code very difficult to read since the
> service dependencies are spread out all over the code.
> Additional issues encountered with annotations used at runtime for
> bytecode manipulations are:
> - only one container is allowed to manipulate the bytecode: if two
> different containers rely on annotations at runtime (say one for
> OSGi and one for persistence for instance), they conflict.
In fact, iPOJO annotations are not used a runtime. There are computed
at compile time.
About container conflicts, it is not an issue. A member used by one
container should not be used by another container (that a well-known
aspect composition issue...).
To handle this, iPOJO provides the "handler" mechanism. An handler can
manage the interaction with your technical services (JPA ... ), and
inject / collect / managed required functionality.
>
> - bytecode manipulations (even offline) make the code very difficult
> to debug since the resulting code can be quite different from the
> originally written code (not to mention that the stack traces
> usually don't match anything anymore)
iPOJO conserves the stack trace and line numbers. So, iPOJO code can
be debugged with any debugger (such as Eclipse).
Clement
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
Marcel Offermans wrote:
> On Feb 5, 2009, at 2:14 , Richard S. Hall wrote:
>
>>> Plus there is probably an argument somewhere that if you put the
>>> annotations into the actual code, then that code can't be used without
>>> the ipojo.annotations jar lying around somewhere.
>>>
>>
>> Certainly wouldn't be able to compile without them, but the API-based
>> approach creates even a stronger dependency, so this really isn't an
>> issue when comparing the two approaches I don't think. You can only get
>> no API dependencies if you use XML.
>
> Well yes and no. Yes, the API based approach creates a strong
> dependency within the BundleActivator. No, there is no API at all in
> the actual POJO. So reusing the POJO becomes easy, only the Activator
> is actually container specific.
Agreed.
Annotations is another form of API that the "POJO" directly depends
upon. Annotations not being a JDK level standard, each container has its
own set. The Activator on the other hand is by definition OSGi specific;
its very goal is to interact with the framework.
Annotations also make the code very difficult to read since the service
dependencies are spread out all over the code.
Additional issues encountered with annotations used at runtime for
bytecode manipulations are:
- only one container is allowed to manipulate the bytecode: if two
different containers rely on annotations at runtime (say one for OSGi
and one for persistence for instance), they conflict.
- bytecode manipulations (even offline) make the code very difficult to
debug since the resulting code can be quite different from the
originally written code (not to mention that the stack traces usually
don't match anything anymore)
Arjun
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Marcel Offermans <ma...@luminis.nl>.
On Feb 5, 2009, at 2:14 , Richard S. Hall wrote:
>> Plus there is probably an argument somewhere that if you put the
>> annotations into the actual code, then that code can't be used
>> without
>> the ipojo.annotations jar lying around somewhere.
>>
>
> Certainly wouldn't be able to compile without them, but the API-based
> approach creates even a stronger dependency, so this really isn't an
> issue when comparing the two approaches I don't think. You can only
> get
> no API dependencies if you use XML.
Well yes and no. Yes, the API based approach creates a strong
dependency within the BundleActivator. No, there is no API at all in
the actual POJO. So reusing the POJO becomes easy, only the Activator
is actually container specific.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trejkaz wrote:
>> I am no big fan of annotations, but I think they are actually less verbose
>> than the API-based approach, because iPOJO reads most default values (e.g.,
>> data type) from the byte code, so they don't need to be specified in iPOJO
>> annotations.
>>
>
> Quite true. I do like the annotations, the problem is that someone
> decided that even when you're using annotations you still need to use
> XML to create the instances. Having realised that annotations no
> longer removed all the need to use XML, I started thinking it would be
> cleaner to put all the OSGi code in one place, which meant using the
> XML for everything...
>
Annotations are used to annotate a component type (i.e., provide
metadata about it). Creating an instance of a component cannot really be
consider metadata about the component, so it doesn't make sense to
attach some sort of "@CreateInstance" tag to the component type, since
the instance creation is dependent the usage scenario and not a
development-time decision (e.g., maybe in some scenarios you want two
instances configured differently at run time and other scenarios you
only want one instance).
If instance creation is not metadata of the component, then where should
it go?
So, this line of reasoning is how iPOJO got to its current approach.
iPOJO allows you to specify it in an XML file, but it also provides a
manifest-based syntax you can use if you really don't want to see any
XML at all (all XML is translated to this manifest-based format anyway,
so you don't have an XML dependency at run time, only compile time).
iPOJO also supports creating instances from ConfigAdmin. But all of this
is based on a normal factory concept. iPOJO registers a Factory service
for the annotated component type in the service registry, so you could
always create your own mechanism for creating an instance by looking up
the factory service in the service registry and creating an instance
yourself.
We pretty much cover all of the bases we can think of, but if you see an
angle we are missing, please open it up for discussion.
> Plus there is probably an argument somewhere that if you put the
> annotations into the actual code, then that code can't be used without
> the ipojo.annotations jar lying around somewhere.
>
Certainly wouldn't be able to compile without them, but the API-based
approach creates even a stronger dependency, so this really isn't an
issue when comparing the two approaches I don't think. You can only get
no API dependencies if you use XML.
> But assuming that this new API will allow configuring both the
> dependencies and the instances, it's an awesome move forward. I'll
> have to check it out some time.
>
Great. Feedback is always welcome.
Keep in mind that the examples for the API-based approach actually are
combining two distinct concepts, the description of the component type
and its configuration and instantiation.
-> richard
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Trejkaz <tr...@trypticon.org>.
> I am no big fan of annotations, but I think they are actually less verbose
> than the API-based approach, because iPOJO reads most default values (e.g.,
> data type) from the byte code, so they don't need to be specified in iPOJO
> annotations.
Quite true. I do like the annotations, the problem is that someone
decided that even when you're using annotations you still need to use
XML to create the instances. Having realised that annotations no
longer removed all the need to use XML, I started thinking it would be
cleaner to put all the OSGi code in one place, which meant using the
XML for everything...
Plus there is probably an argument somewhere that if you put the
annotations into the actual code, then that code can't be used without
the ipojo.annotations jar lying around somewhere.
But assuming that this new API will allow configuring both the
dependencies and the instances, it's an awesome move forward. I'll
have to check it out some time.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trejkaz wrote:
>> public class Activator extends DependencyActivatorBase {
>> public void init(BundleContext c, DependencyManager m) {
>> m.add(createService()
>> .setInterface(FooService.class.getName(), null)
>> .setImplementation(FooServiceImpl.class)
>> .add
>> (createServiceDependency().setClass(BarService.class).setRequired(true))
>> );
>> }
>> }
>>
>
> I think I'll hold off on using iPOJO heavily until this is possible,
> because it's great! I've never been a huge fan of XML because people
> seem to throw it around and try to pretend that it isn't API (Spring
> is one of the greatest offenders here.) In reality it is just more
> API, but which forces you to write your program in two languages. The
> Java equivalent is even more compact than the XML, and Java is already
> pretty verbose!
>
I am no big fan of annotations, but I think they are actually less
verbose than the API-based approach, because iPOJO reads most default
values (e.g., data type) from the byte code, so they don't need to be
specified in iPOJO annotations.
Otherwise, I guess the API-based iPOJO approach will be in trunk shortly.
> I'll have my little complaint though. Fluent doesn't just mean it's
> Java, it means when you read it out loud it almost sounds like
> English. As such you'll notice that fluent APIs don't tend to use the
> word "set" in the method names.
>
> e.g. this is fluent:
>
> assertThat(m, isEqualTo(n));
>
> And this is fluent:
>
> m.add(new Service() {{
> withInterface(FooService.class.getName(),
> null).andImplementation(FooServiceImpl.class);
> withDependencyOn(BarService.class).required();
> withependencyOn(BazService.class, "(name=something)").temporal();
> }});
>
> But the examples posted in this thread thus far, I would not fit into
> the fluent category. They're more like a classical builder API. Not
> that there's anything wrong with that, I just don't want to see people
> start abusing terminology and then (slippery slope) 2 years down the
> track the entire JRE is considered to be a fluent API.
>
Makes sense to me.
-> richard
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Trejkaz <tr...@trypticon.org>.
> public class Activator extends DependencyActivatorBase {
> public void init(BundleContext c, DependencyManager m) {
> m.add(createService()
> .setInterface(FooService.class.getName(), null)
> .setImplementation(FooServiceImpl.class)
> .add
> (createServiceDependency().setClass(BarService.class).setRequired(true))
> );
> }
> }
I think I'll hold off on using iPOJO heavily until this is possible,
because it's great! I've never been a huge fan of XML because people
seem to throw it around and try to pretend that it isn't API (Spring
is one of the greatest offenders here.) In reality it is just more
API, but which forces you to write your program in two languages. The
Java equivalent is even more compact than the XML, and Java is already
pretty verbose!
I'll have my little complaint though. Fluent doesn't just mean it's
Java, it means when you read it out loud it almost sounds like
English. As such you'll notice that fluent APIs don't tend to use the
word "set" in the method names.
e.g. this is fluent:
assertThat(m, isEqualTo(n));
And this is fluent:
m.add(new Service() {{
withInterface(FooService.class.getName(),
null).andImplementation(FooServiceImpl.class);
withDependencyOn(BarService.class).required();
withependencyOn(BazService.class, "(name=something)").temporal();
}});
But the examples posted in this thread thus far, I would not fit into
the fluent category. They're more like a classical builder API. Not
that there's anything wrong with that, I just don't want to see people
start abusing terminology and then (slippery slope) 2 years down the
track the entire JRE is considered to be a fluent API.
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Clement Escoffier <cl...@gmail.com>.
On 04.02.2009, at 15:55, Richard S. Hall wrote:
> Arjun Panday wrote:
>>
>>> One of the cool aspect of iPOJO is that you can use either
>>> annotations (http://felix.apache.org/site/how-to-use-ipojo-annotations.html
>>> , http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf)
>>> , or XML (http://felix.apache.org/site/ipojo-in-10-minutes.html),
>>> or a fluent API.
>> - I thought using annotations still required an extra xml file in
>> the bundle?
>
> No, annotations do not require an XML file. During build, iPOJO
> converts them to an internal format and sticks them in the bundle
> manifest.
The XML file is used to declare instances. However instances can also
be created with the configuration admin (and so doesn't require the
XML file).
>
>
>> - What's the fluent API?
>
> Apparently the new fancy name for Java-based API. :-)
Right :-)
The fluent API is a way to describe iPOJO component type by using an
API. We say 'fluent', just because it always returns the current
object and so you can sequence invocations 'easily'.
The API is still in my sandbox (http://svn.apache.org/viewvc/felix/sandbox/clement/ipojo-utils/org.apache.felix.ipojo.api/
) . I'm waiting to close the iPOJO 1.2.0 release before moving it to
the trunk (with the documentation).
Regards,
Clement
>
>
> -> richard
>
>>
>> Arjun
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Arjun Panday wrote:
>
>> One of the cool aspect of iPOJO is that you can use either
>> annotations
>> (http://felix.apache.org/site/how-to-use-ipojo-annotations.html,
>> http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf),
>> or XML (http://felix.apache.org/site/ipojo-in-10-minutes.html), or a
>> fluent API.
> - I thought using annotations still required an extra xml file in the
> bundle?
No, annotations do not require an XML file. During build, iPOJO converts
them to an internal format and sticks them in the bundle manifest.
> - What's the fluent API?
Apparently the new fancy name for Java-based API. :-)
-> richard
>
> Arjun
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
> One of the cool aspect of iPOJO is that you can use either annotations
> (http://felix.apache.org/site/how-to-use-ipojo-annotations.html,
> http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf),
> or XML (http://felix.apache.org/site/ipojo-in-10-minutes.html), or a
> fluent API.
- I thought using annotations still required an extra xml file in the
bundle?
- What's the fluent API?
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> 2009/2/4 Richard S. Hall <he...@ungoverned.org>
>
>> One day we will get back to our discussion of merging, but until then it
>> would be awesome to have a page that shows back-to-back-to-back comparisons
>> like this of DS, DM, and iPOJO.
>>
>>
>
> +1 ... perhaps create a simple 'standard' app for comparing frameworks?
>
Yes, that would be good. The old hot dog vendor app. ;-)
-> richard
>
>
>> -> richard
>>
>>
>> Clement Escoffier wrote:
>>
>>
>>> On 04.02.2009, at 12:18, Marcel Offermans wrote:
>>>
>>> On Feb 4, 2009, at 12:08 , Clement Escoffier wrote:
>>>
>>>> One of the cool aspect of iPOJO is that you can use [...] a fluent API.
>>>>
>>>> Could you show us what the example you gave looks like using the fluent
>>>> API in iPOJO?
>>>>
>>>>
>>> Sure :
>>>
>>> new PrimitiveComponentType()
>>> .setBundleContext(context)
>>> .setClassName("org.example.impl.FooServiceImpl")
>>> .addService(new Service())
>>> .addDependency(new Dependency().setField("myBar"))
>>> .createInstance();
>>>
>>>
>>> Regards,
>>>
>>>
>>> Clement
>>>
>>>
>>>
>>>> Greetings, Marcel
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/4 Richard S. Hall <he...@ungoverned.org>
> Wow, it's like dueling DI frameworks!
>
ah, the agony of choice... I'm just happy to see people using services ;)
> One day we will get back to our discussion of merging, but until then it
> would be awesome to have a page that shows back-to-back-to-back comparisons
> like this of DS, DM, and iPOJO.
>
+1 ... perhaps create a simple 'standard' app for comparing frameworks?
> -> richard
>
>
> Clement Escoffier wrote:
>
>>
>> On 04.02.2009, at 12:18, Marcel Offermans wrote:
>>
>> On Feb 4, 2009, at 12:08 , Clement Escoffier wrote:
>>>
>>> One of the cool aspect of iPOJO is that you can use [...] a fluent API.
>>>>
>>>
>>> Could you show us what the example you gave looks like using the fluent
>>> API in iPOJO?
>>>
>>
>> Sure :
>>
>> new PrimitiveComponentType()
>> .setBundleContext(context)
>> .setClassName("org.example.impl.FooServiceImpl")
>> .addService(new Service())
>> .addDependency(new Dependency().setField("myBar"))
>> .createInstance();
>>
>>
>> Regards,
>>
>>
>> Clement
>>
>>
>>>
>>> Greetings, Marcel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Neil Bartlett wrote:
> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> Wow, it's like dueling DI frameworks!
>>
>> One day we will get back to our discussion of merging, but until then it
>> would be awesome to have a page that shows back-to-back-to-back comparisons
>> like this of DS, DM, and iPOJO.
>>
>
> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
> that covers exactly this subject, i.e. a comparison of component
> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
> slides and exercises will be made available under EPL shortly.
>
EPL? Ewww....
:-P
-> richard
> The really cool thing is that all these frameworks interoperate
> cleanly at the services level.
>
> Regards,
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Heiko Seeberger <he...@googlemail.com>.
Ray,
Wow, impressive list ;-)
I am one of the funders of the ScalaModules project (Thanx for your
hint, Neil). We have just started and there is very little you can
already see, but we will soon have to have something out, because we
will give talks on ScalaMoudles at EclipseCon and (German) JAX. So
stay tuned. Or even better: Jump in! Your help would be more than
welcome.
Cheers
Heiko
On 06.02.2009, at 15:37, Ray Racine wrote:
> OFF TOPIC: Scala, OSGi and Service Managment.
>
> I'd love to see some small standard app demoing various basic usage
> scenarios with the 3-4 common service frameworks.
>
> I have the luxury of using Scala with my "Java" projects. Scala has
> near
> seamless integration with Java. And I've been successfully using
> Scala with
> Felix without incident for several months.
>
> Bluntly what I see is very smart people developing creative
> solutions to a
> fairly simple problem made complex by the constraints of Java.
>
> So let me correct myself immediately, I'm aware that the "fairly
> simple
> problem" of service management is a minefield of alligators with
> regards to
> concurrency etc. However as I've been reading this thread I can't
> help
> wondering "what would it be like" if DM were written in Scala.
>
> Here are the weapons one would bring to the fight:
>
> 1. Singleton Objects with unambiguous initialization semantics
> (didn't Sun
> give up on have a standard Java util global logger as they simply
> could not
> guarantee initialization?)
>
> 2. Traits, Scala's version of Interfaces, can contain "code" which
> gives you
> Mixins (clean multiple inheritance). Take any plain ol' class and
> Mixin a
> few traits presto, its an OSGi service. Clean separation.
>
> 3. Companion Objects. Scala only provides one and only one
> constructor for
> a Class, but clean syntax for as many Factory Methods as one would
> like.
> e.g. For the Point Class. Ctor: new Point (1,2) FactoryMethod:
> Point
> (1,2) Factory methods look and behave like Ctors without the "new".
>
> 4. First class functions with Closures. Factory Thunks. Create
> "Builder"
> or "Constructor" thunks at runtime and give it to the framework to
> create
> needed services. i.e. Functions which take no arguments but return
> instances of constructed objects initialized with values in its
> "closure".
>
> 5. Any Method can be reified as a function closed over the object
> instance.
>
> 6. All the type parametrization that Java has and much richer.
>
> 7. In Scala everything is an expression. The "return" keyword is
> only used
> to break recursion. The "Fluid" approach is standard SOP. In
> Scala you
> are always chaining. Its pretty rare to have functions and methods
> that
> return "nothing" which is the Scala type Unit. Your code is fluid by
> design.
>
> 8. Scala is OO-Functional. Functional code is "declarative" code.
>
> 9. Concurrency problems. Scala has Erlang like Actors which gives
> you
> Message Passing Concurrency. Other approaches are supported as
> well. But
> consider managing the dynamic nature of OSGi Services events as
> Messages to
> Actors which manage the Service Repository etc. Substantially reduced
> mucking about with mutexs, ReentrantLocks, synch blocks etc... Safe
> concurrent code without alligators lurking to bite you in the ass
> down the
> road. Scala supports immutability hence self-referential methods/
> functions
> which allow you to write concurrent code without ulcers.
>
> 8. DSL capabilities. What are the various efforts here truly all
> about?
> In some sense they are all alternative approaches to create a
> Declarative
> (DSL) Domain Specific Language for Service Management/Composition/
> Dependency
> etc... Its pretty much a question of pick your favorite syntax for
> DSL
> implementation.
>
> - Use XML syntax.
> - Use Annotations.
> - Use Cleverly named Java methods to create an API, combine with
> "Fluid"
> pattern or other cleverness so when you squint at it hard enough it
> looks
> like declarative statements for service management.
> - Use Scala's extended syntax capabilites.
>
> Scala has some very nice capabilities of designing DSLs in Scala. For
> example,
> - Infix and postfix Methods/Operators.
> - Optional use of the '.' to invoke methods. i.e. x.add (y) becomes
> x add
> y. or Service X withInterface Y withImpl Z.
>
> The goal would be to use Scala syntax extensibility to define a clean
> declarative services DSL in Scala itself.
>
> As one can tell I'm a bit fired up to give this a run. Moving
> forward on my
> project I see only further use of OSGi and it looks like I'm going
> to take a
> swag at the Felix DM translated to Scala and see how it goes.
>
> Ray
>
>
> On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett
> <nj...@gmail.com> wrote:
>
>> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall
>> <he...@ungoverned.org>
>> wrote:
>>> Wow, it's like dueling DI frameworks!
>>>
>>> One day we will get back to our discussion of merging, but until
>>> then it
>>> would be awesome to have a page that shows back-to-back-to-back
>> comparisons
>>> like this of DS, DM, and iPOJO.
>>
>> Heiko Seeberger and I will be giving a tutorial at EclipseCon in
>> March
>> that covers exactly this subject, i.e. a comparison of component
>> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
>> slides and exercises will be made available under EPL shortly.
>>
>> The really cool thing is that all these frameworks interoperate
>> cleanly at the services level.
>>
>> Regards,
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
Re: Scala, OSGi and Service Management (was Re: Making sense of
service binding and dependencies)
Posted by Neil Bartlett <nj...@gmail.com>.
Ray,
There are others looking at using Scala with OSGi also, take a look at
the Scala Modules project (http://code.google.com/p/scalamodules/).
Regards,
Neil
On Fri, Feb 6, 2009 at 2:47 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> I don't know much about Scala, but definitely give it a shot. I agree with
> what you say that often we are working around limitations in Java. However,
> the big issue is getting people to venture outside what they already know.
> So, it is already a challenge getting people to try a Java-based DI
> framework, which means that a Scala-based one creates an extra level of
> challenge. But I don't think that should stop you, since you never know what
> has the potential to become popular.
>
> I'd be interested in hearing about it.
>
> -> richard
>
> Ray Racine wrote:
>>
>> OFF TOPIC: Scala, OSGi and Service Managment.
>>
>> I'd love to see some small standard app demoing various basic usage
>> scenarios with the 3-4 common service frameworks.
>>
>> I have the luxury of using Scala with my "Java" projects. Scala has near
>> seamless integration with Java. And I've been successfully using Scala
>> with
>> Felix without incident for several months.
>>
>> Bluntly what I see is very smart people developing creative solutions to
>> a
>> fairly simple problem made complex by the constraints of Java.
>>
>> So let me correct myself immediately, I'm aware that the "fairly simple
>> problem" of service management is a minefield of alligators with regards
>> to
>> concurrency etc. However as I've been reading this thread I can't help
>> wondering "what would it be like" if DM were written in Scala.
>>
>> Here are the weapons one would bring to the fight:
>>
>> 1. Singleton Objects with unambiguous initialization semantics (didn't Sun
>> give up on have a standard Java util global logger as they simply could
>> not
>> guarantee initialization?)
>>
>> 2. Traits, Scala's version of Interfaces, can contain "code" which gives
>> you
>> Mixins (clean multiple inheritance). Take any plain ol' class and Mixin a
>> few traits presto, its an OSGi service. Clean separation.
>>
>> 3. Companion Objects. Scala only provides one and only one constructor
>> for
>> a Class, but clean syntax for as many Factory Methods as one would like.
>> e.g. For the Point Class. Ctor: new Point (1,2) FactoryMethod: Point
>> (1,2) Factory methods look and behave like Ctors without the "new".
>>
>> 4. First class functions with Closures. Factory Thunks. Create "Builder"
>> or "Constructor" thunks at runtime and give it to the framework to create
>> needed services. i.e. Functions which take no arguments but return
>> instances of constructed objects initialized with values in its "closure".
>>
>> 5. Any Method can be reified as a function closed over the object
>> instance.
>>
>> 6. All the type parametrization that Java has and much richer.
>>
>> 7. In Scala everything is an expression. The "return" keyword is only
>> used
>> to break recursion. The "Fluid" approach is standard SOP. In Scala you
>> are always chaining. Its pretty rare to have functions and methods that
>> return "nothing" which is the Scala type Unit. Your code is fluid by
>> design.
>>
>> 8. Scala is OO-Functional. Functional code is "declarative" code.
>>
>> 9. Concurrency problems. Scala has Erlang like Actors which gives you
>> Message Passing Concurrency. Other approaches are supported as well. But
>> consider managing the dynamic nature of OSGi Services events as Messages
>> to
>> Actors which manage the Service Repository etc. Substantially reduced
>> mucking about with mutexs, ReentrantLocks, synch blocks etc... Safe
>> concurrent code without alligators lurking to bite you in the ass down the
>> road. Scala supports immutability hence self-referential
>> methods/functions
>> which allow you to write concurrent code without ulcers.
>>
>> 8. DSL capabilities. What are the various efforts here truly all about?
>> In some sense they are all alternative approaches to create a Declarative
>> (DSL) Domain Specific Language for Service
>> Management/Composition/Dependency
>> etc... Its pretty much a question of pick your favorite syntax for DSL
>> implementation.
>>
>> - Use XML syntax.
>> - Use Annotations.
>> - Use Cleverly named Java methods to create an API, combine with "Fluid"
>> pattern or other cleverness so when you squint at it hard enough it looks
>> like declarative statements for service management.
>> - Use Scala's extended syntax capabilites.
>>
>> Scala has some very nice capabilities of designing DSLs in Scala. For
>> example,
>> - Infix and postfix Methods/Operators.
>> - Optional use of the '.' to invoke methods. i.e. x.add (y) becomes x
>> add
>> y. or Service X withInterface Y withImpl Z.
>>
>> The goal would be to use Scala syntax extensibility to define a clean
>> declarative services DSL in Scala itself.
>>
>> As one can tell I'm a bit fired up to give this a run. Moving forward on
>> my
>> project I see only further use of OSGi and it looks like I'm going to take
>> a
>> swag at the Felix DM translated to Scala and see how it goes.
>>
>> Ray
>>
>>
>> On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett <nj...@gmail.com>
>> wrote:
>>
>>
>>>
>>> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>>
>>>>
>>>> Wow, it's like dueling DI frameworks!
>>>>
>>>> One day we will get back to our discussion of merging, but until then it
>>>> would be awesome to have a page that shows back-to-back-to-back
>>>>
>>>
>>> comparisons
>>>
>>>>
>>>> like this of DS, DM, and iPOJO.
>>>>
>>>
>>> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
>>> that covers exactly this subject, i.e. a comparison of component
>>> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
>>> slides and exercises will be made available under EPL shortly.
>>>
>>> The really cool thing is that all these frameworks interoperate
>>> cleanly at the services level.
>>>
>>> Regards,
>>> Neil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Scala, OSGi and Service Management (was Re: Making sense of service
binding and dependencies)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I don't know much about Scala, but definitely give it a shot. I agree
with what you say that often we are working around limitations in Java.
However, the big issue is getting people to venture outside what they
already know. So, it is already a challenge getting people to try a
Java-based DI framework, which means that a Scala-based one creates an
extra level of challenge. But I don't think that should stop you, since
you never know what has the potential to become popular.
I'd be interested in hearing about it.
-> richard
Ray Racine wrote:
> OFF TOPIC: Scala, OSGi and Service Managment.
>
> I'd love to see some small standard app demoing various basic usage
> scenarios with the 3-4 common service frameworks.
>
> I have the luxury of using Scala with my "Java" projects. Scala has near
> seamless integration with Java. And I've been successfully using Scala with
> Felix without incident for several months.
>
> Bluntly what I see is very smart people developing creative solutions to a
> fairly simple problem made complex by the constraints of Java.
>
> So let me correct myself immediately, I'm aware that the "fairly simple
> problem" of service management is a minefield of alligators with regards to
> concurrency etc. However as I've been reading this thread I can't help
> wondering "what would it be like" if DM were written in Scala.
>
> Here are the weapons one would bring to the fight:
>
> 1. Singleton Objects with unambiguous initialization semantics (didn't Sun
> give up on have a standard Java util global logger as they simply could not
> guarantee initialization?)
>
> 2. Traits, Scala's version of Interfaces, can contain "code" which gives you
> Mixins (clean multiple inheritance). Take any plain ol' class and Mixin a
> few traits presto, its an OSGi service. Clean separation.
>
> 3. Companion Objects. Scala only provides one and only one constructor for
> a Class, but clean syntax for as many Factory Methods as one would like.
> e.g. For the Point Class. Ctor: new Point (1,2) FactoryMethod: Point
> (1,2) Factory methods look and behave like Ctors without the "new".
>
> 4. First class functions with Closures. Factory Thunks. Create "Builder"
> or "Constructor" thunks at runtime and give it to the framework to create
> needed services. i.e. Functions which take no arguments but return
> instances of constructed objects initialized with values in its "closure".
>
> 5. Any Method can be reified as a function closed over the object instance.
>
> 6. All the type parametrization that Java has and much richer.
>
> 7. In Scala everything is an expression. The "return" keyword is only used
> to break recursion. The "Fluid" approach is standard SOP. In Scala you
> are always chaining. Its pretty rare to have functions and methods that
> return "nothing" which is the Scala type Unit. Your code is fluid by
> design.
>
> 8. Scala is OO-Functional. Functional code is "declarative" code.
>
> 9. Concurrency problems. Scala has Erlang like Actors which gives you
> Message Passing Concurrency. Other approaches are supported as well. But
> consider managing the dynamic nature of OSGi Services events as Messages to
> Actors which manage the Service Repository etc. Substantially reduced
> mucking about with mutexs, ReentrantLocks, synch blocks etc... Safe
> concurrent code without alligators lurking to bite you in the ass down the
> road. Scala supports immutability hence self-referential methods/functions
> which allow you to write concurrent code without ulcers.
>
> 8. DSL capabilities. What are the various efforts here truly all about?
> In some sense they are all alternative approaches to create a Declarative
> (DSL) Domain Specific Language for Service Management/Composition/Dependency
> etc... Its pretty much a question of pick your favorite syntax for DSL
> implementation.
>
> - Use XML syntax.
> - Use Annotations.
> - Use Cleverly named Java methods to create an API, combine with "Fluid"
> pattern or other cleverness so when you squint at it hard enough it looks
> like declarative statements for service management.
> - Use Scala's extended syntax capabilites.
>
> Scala has some very nice capabilities of designing DSLs in Scala. For
> example,
> - Infix and postfix Methods/Operators.
> - Optional use of the '.' to invoke methods. i.e. x.add (y) becomes x add
> y. or Service X withInterface Y withImpl Z.
>
> The goal would be to use Scala syntax extensibility to define a clean
> declarative services DSL in Scala itself.
>
> As one can tell I'm a bit fired up to give this a run. Moving forward on my
> project I see only further use of OSGi and it looks like I'm going to take a
> swag at the Felix DM translated to Scala and see how it goes.
>
> Ray
>
>
> On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett <nj...@gmail.com> wrote:
>
>
>> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>>
>>> Wow, it's like dueling DI frameworks!
>>>
>>> One day we will get back to our discussion of merging, but until then it
>>> would be awesome to have a page that shows back-to-back-to-back
>>>
>> comparisons
>>
>>> like this of DS, DM, and iPOJO.
>>>
>> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
>> that covers exactly this subject, i.e. a comparison of component
>> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
>> slides and exercises will be made available under EPL shortly.
>>
>> The really cool thing is that all these frameworks interoperate
>> cleanly at the services level.
>>
>> Regards,
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Ray Racine <ra...@gmail.com>.
OFF TOPIC: Scala, OSGi and Service Managment.
I'd love to see some small standard app demoing various basic usage
scenarios with the 3-4 common service frameworks.
I have the luxury of using Scala with my "Java" projects. Scala has near
seamless integration with Java. And I've been successfully using Scala with
Felix without incident for several months.
Bluntly what I see is very smart people developing creative solutions to a
fairly simple problem made complex by the constraints of Java.
So let me correct myself immediately, I'm aware that the "fairly simple
problem" of service management is a minefield of alligators with regards to
concurrency etc. However as I've been reading this thread I can't help
wondering "what would it be like" if DM were written in Scala.
Here are the weapons one would bring to the fight:
1. Singleton Objects with unambiguous initialization semantics (didn't Sun
give up on have a standard Java util global logger as they simply could not
guarantee initialization?)
2. Traits, Scala's version of Interfaces, can contain "code" which gives you
Mixins (clean multiple inheritance). Take any plain ol' class and Mixin a
few traits presto, its an OSGi service. Clean separation.
3. Companion Objects. Scala only provides one and only one constructor for
a Class, but clean syntax for as many Factory Methods as one would like.
e.g. For the Point Class. Ctor: new Point (1,2) FactoryMethod: Point
(1,2) Factory methods look and behave like Ctors without the "new".
4. First class functions with Closures. Factory Thunks. Create "Builder"
or "Constructor" thunks at runtime and give it to the framework to create
needed services. i.e. Functions which take no arguments but return
instances of constructed objects initialized with values in its "closure".
5. Any Method can be reified as a function closed over the object instance.
6. All the type parametrization that Java has and much richer.
7. In Scala everything is an expression. The "return" keyword is only used
to break recursion. The "Fluid" approach is standard SOP. In Scala you
are always chaining. Its pretty rare to have functions and methods that
return "nothing" which is the Scala type Unit. Your code is fluid by
design.
8. Scala is OO-Functional. Functional code is "declarative" code.
9. Concurrency problems. Scala has Erlang like Actors which gives you
Message Passing Concurrency. Other approaches are supported as well. But
consider managing the dynamic nature of OSGi Services events as Messages to
Actors which manage the Service Repository etc. Substantially reduced
mucking about with mutexs, ReentrantLocks, synch blocks etc... Safe
concurrent code without alligators lurking to bite you in the ass down the
road. Scala supports immutability hence self-referential methods/functions
which allow you to write concurrent code without ulcers.
8. DSL capabilities. What are the various efforts here truly all about?
In some sense they are all alternative approaches to create a Declarative
(DSL) Domain Specific Language for Service Management/Composition/Dependency
etc... Its pretty much a question of pick your favorite syntax for DSL
implementation.
- Use XML syntax.
- Use Annotations.
- Use Cleverly named Java methods to create an API, combine with "Fluid"
pattern or other cleverness so when you squint at it hard enough it looks
like declarative statements for service management.
- Use Scala's extended syntax capabilites.
Scala has some very nice capabilities of designing DSLs in Scala. For
example,
- Infix and postfix Methods/Operators.
- Optional use of the '.' to invoke methods. i.e. x.add (y) becomes x add
y. or Service X withInterface Y withImpl Z.
The goal would be to use Scala syntax extensibility to define a clean
declarative services DSL in Scala itself.
As one can tell I'm a bit fired up to give this a run. Moving forward on my
project I see only further use of OSGi and it looks like I'm going to take a
swag at the Felix DM translated to Scala and see how it goes.
Ray
On Wed, Feb 4, 2009 at 10:54 AM, Neil Bartlett <nj...@gmail.com> wrote:
> On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org>
> wrote:
> > Wow, it's like dueling DI frameworks!
> >
> > One day we will get back to our discussion of merging, but until then it
> > would be awesome to have a page that shows back-to-back-to-back
> comparisons
> > like this of DS, DM, and iPOJO.
>
> Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
> that covers exactly this subject, i.e. a comparison of component
> frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
> slides and exercises will be made available under EPL shortly.
>
> The really cool thing is that all these frameworks interoperate
> cleanly at the services level.
>
> Regards,
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Making sense of service binding and dependencies
Posted by Neil Bartlett <nj...@gmail.com>.
On Wed, Feb 4, 2009 at 2:52 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Wow, it's like dueling DI frameworks!
>
> One day we will get back to our discussion of merging, but until then it
> would be awesome to have a page that shows back-to-back-to-back comparisons
> like this of DS, DM, and iPOJO.
Heiko Seeberger and I will be giving a tutorial at EclipseCon in March
that covers exactly this subject, i.e. a comparison of component
frameworks for OSGi including DS, DM, iPOJO and possibly Guice. Our
slides and exercises will be made available under EPL shortly.
The really cool thing is that all these frameworks interoperate
cleanly at the services level.
Regards,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Wow, it's like dueling DI frameworks!
One day we will get back to our discussion of merging, but until then it
would be awesome to have a page that shows back-to-back-to-back
comparisons like this of DS, DM, and iPOJO.
-> richard
Clement Escoffier wrote:
>
> On 04.02.2009, at 12:18, Marcel Offermans wrote:
>
>> On Feb 4, 2009, at 12:08 , Clement Escoffier wrote:
>>
>>> One of the cool aspect of iPOJO is that you can use [...] a fluent API.
>>
>> Could you show us what the example you gave looks like using the
>> fluent API in iPOJO?
>
> Sure :
>
> new PrimitiveComponentType()
> .setBundleContext(context)
> .setClassName("org.example.impl.FooServiceImpl")
> .addService(new Service())
> .addDependency(new Dependency().setField("myBar"))
> .createInstance();
>
>
> Regards,
>
>
> Clement
>
>>
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Clement Escoffier <cl...@gmail.com>.
On 04.02.2009, at 12:18, Marcel Offermans wrote:
> On Feb 4, 2009, at 12:08 , Clement Escoffier wrote:
>
>> One of the cool aspect of iPOJO is that you can use [...] a fluent
>> API.
>
> Could you show us what the example you gave looks like using the
> fluent API in iPOJO?
Sure :
new PrimitiveComponentType()
.setBundleContext(context)
.setClassName("org.example.impl.FooServiceImpl")
.addService(new Service())
.addDependency(new Dependency().setField("myBar"))
.createInstance();
Regards,
Clement
>
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Making sense of service binding and dependencies
Posted by Marcel Offermans <ma...@luminis.nl>.
On Feb 4, 2009, at 12:08 , Clement Escoffier wrote:
> One of the cool aspect of iPOJO is that you can use [...] a fluent
> API.
Could you show us what the example you gave looks like using the
fluent API in iPOJO?
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Clement Escoffier <cl...@gmail.com>.
On 04.02.2009, at 11:36, Marcel Offermans wrote:
> On Feb 4, 2009, at 11:16 , Clement Escoffier wrote:
>
>>> DependencyManager and iPOJO definitely can help too. The benefit of
>>> these types of dependency injection tools is that they actually
>>> manage the life cycle of your component, so it won't even be created
>>> until your dependencies are satisfied. Check out my iPOJO
>>> presentation under the presentations section of the documentation
>>> page on the Felix web site for a simple example at the beginning of
>>> the presentation for how you provide and require services in iPOJO,
>>> as an example.
>>
>> Here is a simple example of how to implement it with iPOJO:
>>
>> @Component
>> @Provides
>> public class FooServiceImpl implements FooService {
>> @Requires
>> private BarService myBar;
>>
>> public void doSomething() {
>> myBar.doSomethingWithBar();
>> }
>> }
>>
>> That's simple, isn't it ? You don't have to worry about BarService
>> availability, iPOJO will manage this for you :-)
>
> And the same thing in the DependencyManager:
>
> public class FooServiceImpl implements FooService {
> private volatile BarService myBar;
>
> public void doSomething() {
> myBar.doSomethingWithBar();
> }
> }
>
> public class Activator extends DependencyActivatorBase {
> public void init(BundleContext c, DependencyManager m) {
> m.add(createService()
> .setInterface(FooService.class.getName(), null)
> .setImplementation(FooServiceImpl.class)
> .add
> (createServiceDependency
> ().setClass(BarService.class).setRequired(true))
> );
> }
> }
>
> Here you need no annotations at all in your POJO, all OSGi specific
> code is in the Activator, and you can define your services and their
> dependencies using a fluent API.
One of the cool aspect of iPOJO is that you can use either annotations
(http://felix.apache.org/site/how-to-use-ipojo-annotations.html, http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf)
, or XML (http://felix.apache.org/site/ipojo-in-10-minutes.html), or a
fluent API.
Clement
>
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Marcel Offermans <ma...@luminis.nl>.
On Feb 4, 2009, at 11:16 , Clement Escoffier wrote:
>> DependencyManager and iPOJO definitely can help too. The benefit of
>> these types of dependency injection tools is that they actually
>> manage the life cycle of your component, so it won't even be created
>> until your dependencies are satisfied. Check out my iPOJO
>> presentation under the presentations section of the documentation
>> page on the Felix web site for a simple example at the beginning of
>> the presentation for how you provide and require services in iPOJO,
>> as an example.
>
> Here is a simple example of how to implement it with iPOJO:
>
> @Component
> @Provides
> public class FooServiceImpl implements FooService {
> @Requires
> private BarService myBar;
>
> public void doSomething() {
> myBar.doSomethingWithBar();
> }
> }
>
> That's simple, isn't it ? You don't have to worry about BarService
> availability, iPOJO will manage this for you :-)
And the same thing in the DependencyManager:
public class FooServiceImpl implements FooService {
private volatile BarService myBar;
public void doSomething() {
myBar.doSomethingWithBar();
}
}
public class Activator extends DependencyActivatorBase {
public void init(BundleContext c, DependencyManager m) {
m.add(createService()
.setInterface(FooService.class.getName(), null)
.setImplementation(FooServiceImpl.class)
.add
(createServiceDependency().setClass(BarService.class).setRequired(true))
);
}
}
Here you need no annotations at all in your POJO, all OSGi specific
code is in the Activator, and you can define your services and their
dependencies using a fluent API.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 04.02.2009, at 05:15, Richard S. Hall wrote:
> Gerald Bortis wrote:
>> Hi all,
>>
>> I've been playing with OSGi and Felix for the past week, and I
>> think I have
>> a general understanding of how to apply it to my application. So
>> far, I've
>> refactored my code into bundle-friendly packages and have setup a
>> build
>> system to generate my bundles. For every bundle, I have the following
>> pattern:
>>
>> FooActivator.java
>> FooService.java
>> FooServiceImpl.java
>>
>
> Looks good.
>
>> FooActivator implements BundleActivator, and in the start method
>> registers
>> FooService. Pretty straightforward. The issues I've run into are the
>> following:
>>
>> a) What is the best way to call BarService from FooServiceImpl?
>> I've tried
>> both the ServiceTracker pattern, and the ServiceBinding-Utils, but
>> both seem
>> a bit convoluted.
>>
>
> At a minimum, you should use the ServiceTracker (you could also
> register a service listener and do your own service tracking, but
> this is not recommended). With a ServiceTracker, you could use a
> ServiceTrackerCustomizer to call you when a service is available,
> for example.
>
>> b) What is the best way to make sure that FooServiceImpl doesn't call
>> BarService before BarService has been reigstered?
>>
>
> If you use a ServiceTrackerCustomerizer, it will only be called when
> a BarService is available.
>
>> For the second issue, I thought I was on the right path when I
>> found the
>> Depedency Manager bundle, but the example isn't clear how
>> registering a
>> ServiceDepedency on BarService instantiates the instance that
>> FooServiceImpl
>> requires? This lead me to the iPOJO section, which promises to
>> address these
>> issues, but I'm not sure if it's what I'm looking for either. Does
>> using
>> Dependency Manager or iPOJOs also address my first issue of how to
>> implicity
>> bind the services? Any pointers in the right direction are
>> appreciated.
>>
>
> DependencyManager and iPOJO definitely can help too. The benefit of
> these types of dependency injection tools is that they actually
> manage the life cycle of your component, so it won't even be created
> until your dependencies are satisfied. Check out my iPOJO
> presentation under the presentations section of the documentation
> page on the Felix web site for a simple example at the beginning of
> the presentation for how you provide and require services in iPOJO,
> as an example.
Here is a simple example of how to implement it with iPOJO:
@Component
@Provides
public class FooServiceImpl implements FooService {
@Requires
private BarService myBar;
public void doSomething() {
myBar.doSomethingWithBar();
}
}
That's simple, isn't it ? You don't have to worry about BarService
availability, iPOJO will manage this for you :-)
Clement
>
>
> -> richard
>
>> Regards,
>> Gerald
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Making sense of service binding and dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Gerald Bortis wrote:
> Hi all,
>
> I've been playing with OSGi and Felix for the past week, and I think I have
> a general understanding of how to apply it to my application. So far, I've
> refactored my code into bundle-friendly packages and have setup a build
> system to generate my bundles. For every bundle, I have the following
> pattern:
>
> FooActivator.java
> FooService.java
> FooServiceImpl.java
>
Looks good.
> FooActivator implements BundleActivator, and in the start method registers
> FooService. Pretty straightforward. The issues I've run into are the
> following:
>
> a) What is the best way to call BarService from FooServiceImpl? I've tried
> both the ServiceTracker pattern, and the ServiceBinding-Utils, but both seem
> a bit convoluted.
>
At a minimum, you should use the ServiceTracker (you could also register
a service listener and do your own service tracking, but this is not
recommended). With a ServiceTracker, you could use a
ServiceTrackerCustomizer to call you when a service is available, for
example.
> b) What is the best way to make sure that FooServiceImpl doesn't call
> BarService before BarService has been reigstered?
>
If you use a ServiceTrackerCustomerizer, it will only be called when a
BarService is available.
> For the second issue, I thought I was on the right path when I found the
> Depedency Manager bundle, but the example isn't clear how registering a
> ServiceDepedency on BarService instantiates the instance that FooServiceImpl
> requires? This lead me to the iPOJO section, which promises to address these
> issues, but I'm not sure if it's what I'm looking for either. Does using
> Dependency Manager or iPOJOs also address my first issue of how to implicity
> bind the services? Any pointers in the right direction are appreciated.
>
DependencyManager and iPOJO definitely can help too. The benefit of
these types of dependency injection tools is that they actually manage
the life cycle of your component, so it won't even be created until your
dependencies are satisfied. Check out my iPOJO presentation under the
presentations section of the documentation page on the Felix web site
for a simple example at the beginning of the presentation for how you
provide and require services in iPOJO, as an example.
-> richard
> Regards,
> Gerald
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org