You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Todor Boev <t....@prosyst.bg> on 2008/10/27 19:03:17 UTC
IPojo - universe of components?
Hello,
I was wondering what is iPojo's mission in life: just to make it a bit
easier to code in OSGi or the grand idea to lift the Java language to a
higher abstraction. This philosophical question is important to me
because iPojo like most other DI frameworks seems highly viral.
For example suppose I start out with a single component class that
creates all it's collaborators with POJN (Plain Old Java New :). At this
point I will have to inject all service dependencies into this
uber-component and have it pass them on to the constructors of it's
collaborators. Soon I get sick of my bad style and decide to let iPojo
manage the collaborators and pass around the dependencies for me. And as
soon as the collaborators are under iPojo's wing all classes that need
them will also have to be iPojo managed. And so in no time almost all my
classes will be components. All that will be left are light-weight data
objects and static utilities. The former could soon acquire behavior of
their own and will inevitably become components because they will likely
need to collaborate with other components. As for the static utilities:
unless they are bundles of stand-alone purely functional methods they
are a bad style to begin with and should be re-cast as singleton
components. So if I go with the flow I should have a universe of components.
Is this the way to work with iPojo? Or should restrict iPojo to only the
core graph of long-lived objects that form the basis of my program and
manage the construction, and lifecycle of the more volatile object
generations by hand?
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by Todor Boev <t....@prosyst.bg>.
I suppose I am looking at iPojo from the perspective of Guice and
PicoContainer. The first tries to replace all object construction, while
the second tries to do that and on top of it manage the subsequent
lifecycle of objects. Still both of them operate within the usual OO
paradigm. They just try to enrich the Java language with facilities that
make it easier to do OOP.
iPojo seems to come from some "component" world which I have not grasped
well yet. Seems component != object and one should not strive to make a
component out of every object :)
Hope I have not made this thread too philosophical and tedious to read :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by clement escoffier <cl...@gmail.com>.
2008/11/1 Todor Boev <ri...@gmail.com>
> clement escoffier wrote:
>
> > That is not directly possible. However, you can do this as following:
> > public class ConsumerImpl {
> > // Temporal dependency on FooService
> > FooService fs;
> >
> > // An helper object
> > ConsumerHelper helper;
> >
> >
> > public ConsumerImpl() {
> > helper = new ConsumerHelper(new FooService() {
> > public void doSomething() {
> > System.out.println("Delegate on fs");
> > // Use the temporal dependency
> > fs.doSomething();
> > }
> > });
> >
> > }
> > }
> >
> > So, you create a kind of smart proxy delegating on the temporal
> dependency
> > (on regular dependency). By doing this:
> > - The helper object inherits of the dependency behavior
> > (default-implementation, nullable ...)
> > - You can control the delegation policy
>
> According to this FAQ item:
>
>
> http://felix.apache.org/site/accessing-services-inside-inner-and-anonymous-classes.html
>
> I need to have a getter method, which the smart proxy must call and than
> delegate to the returned
> instance. Otherwise I will jump over all the nice instrumentation iPojo has
> added for the
> "FooService fs;" field. Is this FAQ still valid or does iPojo now
> instrument the inner classes as
> well? (I certainly hope it does :)
This is a major improvement of the 1.0.0 version. Now, iPOJO is able to
inject fields inside inner and nested classes. The FAQ entry is not up to
date, and I'm going to fix it right now :)
Regards,
Clement
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: IPojo - universe of components?
Posted by Todor Boev <ri...@gmail.com>.
clement escoffier wrote:
> That is not directly possible. However, you can do this as following:
> public class ConsumerImpl {
> // Temporal dependency on FooService
> FooService fs;
>
> // An helper object
> ConsumerHelper helper;
>
>
> public ConsumerImpl() {
> helper = new ConsumerHelper(new FooService() {
> public void doSomething() {
> System.out.println("Delegate on fs");
> // Use the temporal dependency
> fs.doSomething();
> }
> });
>
> }
> }
>
> So, you create a kind of smart proxy delegating on the temporal dependency
> (on regular dependency). By doing this:
> - The helper object inherits of the dependency behavior
> (default-implementation, nullable ...)
> - You can control the delegation policy
According to this FAQ item:
http://felix.apache.org/site/accessing-services-inside-inner-and-anonymous-classes.html
I need to have a getter method, which the smart proxy must call and than delegate to the returned
instance. Otherwise I will jump over all the nice instrumentation iPojo has added for the
"FooService fs;" field. Is this FAQ still valid or does iPojo now instrument the inner classes as
well? (I certainly hope it does :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by Todor Boev <t....@prosyst.bg>.
clement escoffier wrote:
> That is not directly possible. However, you can do this as following:
> public class ConsumerImpl {
> // Temporal dependency on FooService
> FooService fs;
>
> // An helper object
> ConsumerHelper helper;
>
>
> public ConsumerImpl() {
> helper = new ConsumerHelper(new FooService() {
> public void doSomething() {
> System.out.println("Delegate on fs");
> // Use the temporal dependency
> fs.doSomething();
> }
> });
>
> }
> }
>
> So, you create a kind of smart proxy delegating on the temporal dependency
> (on regular dependency). By doing this:
> - The helper object inherits of the dependency behavior
> (default-implementation, nullable ...)
> - You can control the delegation policy
According to this FAQ item:
http://felix.apache.org/site/accessing-services-inside-inner-and-anonymous-classes.html
the above example will not work unless a getFooService() method is added to the outer component.
Than the anonymous proxy must delegate to the service using the getter:
getFooService().doSomething(). Did you make an innocent mistake or iPojo now instruments the
internal classes as well as the component class? (I certainly hope so :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by clement escoffier <cl...@gmail.com>.
2008/10/30 Todor Boev <t....@prosyst.bg>
> Richard S. Hall wrote:
>
>> Yes, this is an open-ended question and there is likely no single answer.
>>
>> The mission of iPOJO is to make creating dynamic applications simpler.
>> Precisely how you use it to accomplish this depends on your use case.
>>
>> The main debate, it seems, is when to use an object and when to use a
>> component. Since iPOJO components handle dynamism (among other things), you
>> may choose to use it for those pieces of your application that require
>> dynamism, for example, but it is difficult to say when to decide between
>> object vs component. Granularity is another metric.
>>
>> iPOJO is a full-blown, hierarchical component model built on top of an
>> object-oriented language. In the end, it leaves these decisions up to you.
>>
>> -> richard
>>
>> Does this mean iPojo strives to make it easy for me to smoothly evolve my
> bundle through the entire continuum starting from one-uber-component and
> ending at all-is-component? Naturally I am free to stop at any appropriate
> point during this evolution.
>
> On the practical side:
>
> 1) Is it possible (and ideally easy and clean) for components to create,
> configure and manage the lifecycle of other components at runtime? This is
> required for all stages where near the all-is-component point as I replace
> more and more of the traditional object construction with the
> higher-abstraction of component instance construction. Still not all
> components need to exist all the time - in fact only a small set of "core"
> components do. For example in the classical runtime scope hierarchy of
> application-session-request only the application scoped components exist all
> the time while the session and request scoped components must be created and
> destroyed depending on the number and state of sessions.
Yes, it is possible. By using the iPOJO factory principles, you can create,
(re)configure, start, stop and dispose instances. Factories are accessible
trough the OSGi registry, and so those operations are accessible from your
code.
>
>
> 2) If a component propagates a service dependency to objects that are
> created in the traditional way will iPojo support that dependency within
> these objects?. For example consider the case when a component has a
> temporal dependency. That component creates a new object and passes the
> dependency to it. Later some code within this new object calls the
> dependency. Will iPojo perform all the required management of this call:
> block for the required period and when it expires throw an exception or
> delegate to a default implementation? Things like these are again required
> for all the "mixed" stages where the create-configure-start-stop-destroy
> state machine of some objects is managed by iPojo and of other objects by
> the programmer.
That is not directly possible. However, you can do this as following:
public class ConsumerImpl {
// Temporal dependency on FooService
FooService fs;
// An helper object
ConsumerHelper helper;
public ConsumerImpl() {
helper = new ConsumerHelper(new FooService() {
public void doSomething() {
System.out.println("Delegate on fs");
// Use the temporal dependency
fs.doSomething();
}
});
}
}
So, you create a kind of smart proxy delegating on the temporal dependency
(on regular dependency). By doing this:
- The helper object inherits of the dependency behavior
(default-implementation, nullable ...)
- You can control the delegation policy
Regards,
Clement
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: IPojo - universe of components?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Todor Boev wrote:
> Richard S. Hall wrote:
>> Yes, this is an open-ended question and there is likely no single
>> answer.
>>
>> The mission of iPOJO is to make creating dynamic applications
>> simpler. Precisely how you use it to accomplish this depends on your
>> use case.
>>
>> The main debate, it seems, is when to use an object and when to use a
>> component. Since iPOJO components handle dynamism (among other
>> things), you may choose to use it for those pieces of your
>> application that require dynamism, for example, but it is difficult
>> to say when to decide between object vs component. Granularity is
>> another metric.
>>
>> iPOJO is a full-blown, hierarchical component model built on top of
>> an object-oriented language. In the end, it leaves these decisions up
>> to you.
>>
>> -> richard
>>
> Does this mean iPojo strives to make it easy for me to smoothly evolve
> my bundle through the entire continuum starting from
> one-uber-component and ending at all-is-component? Naturally I am free
> to stop at any appropriate point during this evolution.
I wouldn't say that iPOJO strives to make that easy for you, but it
should support the approach that you choose. iPOJO strives to make
highly dynamic applications as easy to create as non-dynamic
applications. Of course, static applications are a subset of dynamic
applications, so it can still make your life easier (e.g., dependency
injection, configuration injection, etc) in that case too.
Originally, the focus of iPOJO was to simplify OSGi application
development and create a component model that enabled seamless,
transparent integration with OSGi's dynamic service model. It was not
really a goal to have iPOJO also define how you created your inner
objects and/or smaller-grained components. However, over time it has
moved into this direction and will probably continue to do so. Clement
and I were recently talking about more features on the roadmap that move
iPOJO further in this direction. So the answer to this question is evolving.
>
> On the practical side:
>
> 1) Is it possible (and ideally easy and clean) for components to
> create, configure and manage the lifecycle of other components at
> runtime? This is required for all stages where near the
> all-is-component point as I replace more and more of the traditional
> object construction with the higher-abstraction of component instance
> construction. Still not all components need to exist all the time - in
> fact only a small set of "core" components do. For example in the
> classical runtime scope hierarchy of application-session-request only
> the application scoped components exist all the time while the session
> and request scoped components must be created and destroyed depending
> on the number and state of sessions.
As Clement mentioned, you can manage component lifecycle through iPOJO
component factory services, not to be confused with OSGi service
factories. I think composite components might also be interesting to you
here, since you can create a composite component that is really a
composition of smaller components. The resulting composite is just like
any normal component, meaning you can create instance of it and iPOJO
will manage it according to the needs of its internal composition.
> 2) If a component propagates a service dependency to objects that are
> created in the traditional way will iPojo support that dependency
> within these objects?. For example consider the case when a component
> has a temporal dependency. That component creates a new object and
> passes the dependency to it. Later some code within this new object
> calls the dependency. Will iPojo perform all the required management
> of this call: block for the required period and when it expires throw
> an exception or delegate to a default implementation? Things like
> these are again required for all the "mixed" stages where the
> create-configure-start-stop-destroy state machine of some objects is
> managed by iPojo and of other objects by the programmer.
iPOJO does not proxy services to avoid the performance penalty. So, if
you pass a reference to a service you are passing an unmanaged object.
Although it is not necessarily optimal, as Clement points out you can
fairly easily create your own kinds of proxies in iPOJO (typically with
temporal dependencies) to address this situation. Of course, if you have
a suggestion for ways to improve this approach, please file a RFE in
JIRA for iPOJO.
Thanks for the interesting questions.
-> richard
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Todor Boev <t....@prosyst.bg>.
Richard S. Hall wrote:
> Yes, this is an open-ended question and there is likely no single answer.
>
> The mission of iPOJO is to make creating dynamic applications simpler.
> Precisely how you use it to accomplish this depends on your use case.
>
> The main debate, it seems, is when to use an object and when to use a
> component. Since iPOJO components handle dynamism (among other
> things), you may choose to use it for those pieces of your application
> that require dynamism, for example, but it is difficult to say when to
> decide between object vs component. Granularity is another metric.
>
> iPOJO is a full-blown, hierarchical component model built on top of an
> object-oriented language. In the end, it leaves these decisions up to
> you.
>
> -> richard
>
Does this mean iPojo strives to make it easy for me to smoothly evolve
my bundle through the entire continuum starting from one-uber-component
and ending at all-is-component? Naturally I am free to stop at any
appropriate point during this evolution.
On the practical side:
1) Is it possible (and ideally easy and clean) for components to create,
configure and manage the lifecycle of other components at runtime? This
is required for all stages where near the all-is-component point as I
replace more and more of the traditional object construction with the
higher-abstraction of component instance construction. Still not all
components need to exist all the time - in fact only a small set of
"core" components do. For example in the classical runtime scope
hierarchy of application-session-request only the application scoped
components exist all the time while the session and request scoped
components must be created and destroyed depending on the number and
state of sessions.
2) If a component propagates a service dependency to objects that are
created in the traditional way will iPojo support that dependency within
these objects?. For example consider the case when a component has a
temporal dependency. That component creates a new object and passes the
dependency to it. Later some code within this new object calls the
dependency. Will iPojo perform all the required management of this call:
block for the required period and when it expires throw an exception or
delegate to a default implementation? Things like these are again
required for all the "mixed" stages where the
create-configure-start-stop-destroy state machine of some objects is
managed by iPojo and of other objects by the programmer.
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, this is an open-ended question and there is likely no single answer.
The mission of iPOJO is to make creating dynamic applications simpler.
Precisely how you use it to accomplish this depends on your use case.
The main debate, it seems, is when to use an object and when to use a
component. Since iPOJO components handle dynamism (among other things),
you may choose to use it for those pieces of your application that
require dynamism, for example, but it is difficult to say when to decide
between object vs component. Granularity is another metric.
iPOJO is a full-blown, hierarchical component model built on top of an
object-oriented language. In the end, it leaves these decisions up to you.
-> richard
Todor Boev wrote:
> Hello,
> I was wondering what is iPojo's mission in life: just to make it a bit
> easier to code in OSGi or the grand idea to lift the Java language to
> a higher abstraction. This philosophical question is important to me
> because iPojo like most other DI frameworks seems highly viral.
>
> For example suppose I start out with a single component class that
> creates all it's collaborators with POJN (Plain Old Java New :). At
> this point I will have to inject all service dependencies into this
> uber-component and have it pass them on to the constructors of it's
> collaborators. Soon I get sick of my bad style and decide to let
> iPojo manage the collaborators and pass around the dependencies for
> me. And as soon as the collaborators are under iPojo's wing all
> classes that need them will also have to be iPojo managed. And so in
> no time almost all my classes will be components. All that will be
> left are light-weight data objects and static utilities. The former
> could soon acquire behavior of their own and will inevitably become
> components because they will likely need to collaborate with other
> components. As for the static utilities: unless they are bundles of
> stand-alone purely functional methods they are a bad style to begin
> with and should be re-cast as singleton components. So if I go with
> the flow I should have a universe of components.
>
> Is this the way to work with iPojo? Or should restrict iPojo to only
> the core graph of long-lived objects that form the basis of my program
> and manage the construction, and lifecycle of the more volatile object
> generations by hand?
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Peter Kriens <pe...@aqute.biz>.
I think this is an invalid judgement of this landscape.
The OSGi standardized the foundation on which iPOJO rests. This
foundation provides the interoperability between different bundles.
Bundles written with iPOJO work seamlessly with bundles written in
Spring DM, Dependency Manager, or Declarative Services. So iPOJO is
not an -interoperability- technique, it uses OSGi services for this.
So the standard/non standard nature of iPOJO is not that relevant, as
long as it interoperates with other bundles. It is more an
implementation technique to reduce the amount of code one has to write.
Kind regards,
Peter Kriens
On 28 okt 2008, at 17:03, Kit Plummer wrote:
> Brad,
>
> I would warn against the non-standard nature of iPojo. Not to say
> that it is a bad thing, but given the landscape and "components" I
> think you'll struggle with different issues moving in that
> direction. Sure, you may resolve component dependencies - cleaner.
> But, the risk is that your component no longer travels well.
>
> Kit
>
>
> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>
>> I'm totally new to iPOJO but have been pusing components forever.
>> But I'm guessing this fine- vs coarse-grained distinction is
>> precisely the problem I've been struggling with org.jdom, with lots
>> of hand-on help from P. Kriens. So far its defeated both of us.
>>
>> It seems JDOM is what you called a coarse-grained component,
>> developed long before this fine-grained ipojo stuff was around.
>> Deeply entangled with even lower-level dependencies, like Xerces.
>> So I've started looking at iPOJO to see whether that might be a way
>> forward.
>>
>> I'm hoping to find a way to include jdom+dependencies in one of my
>> ipojos so other ipojos can resolve it from there. Seems
>> straightforward on the surface, if I can avoid whatever is breaking
>> bnd now.
>>
>> Clement Escoffier wrote:
>>> Hi,
>>> That’s an interesting question. I would say that it slightly
>>> depend of your use case. However, in one level of abstraction,
>>> being consistent sounds reasonable. To illustrate this, I’m going
>>> to describe two different types of projects choosing the different
>>> strategies: a universe of fine-grain components, and a universe of
>>> coarse-grain components (using regular object collaborators).
>>> In a project aiming to design and implement a residential gateway,
>>> the granularity of components is rather fine-grain. The most part
>>> of the functionalities are implemented inside components and are
>>> available through services, such as devices, technical services,
>>> and internal application services. For this latter case, using
>>> iPOJO composite was crucial to maintain the isolation of internal
>>> services that must not be accessible outside the application (by
>>> peer that are not a part of the application). This granularity was
>>> chosen because of the required flexibility for runtime evolution
>>> (application updates, modifications of the environment…). In
>>> this use case, “everything was dynamic”.
>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>>> technical services provided by the JEE server is implemented by
>>> iPOJO components and provided as OSGi services. Two aspects
>>> motivated this choice. First, the Jonas team wanted to reuse the
>>> most part of their code (makes sense right?). Then, the unit of
>>> evolution (update) is the technical service (coarse-grain). So, in
>>> conclusion, it’s an open question ☺. There is no generic
>>> answer. iPOJO does not influence one or another way, because IMHO
>>> it depends of the use case. The goal of iPOJO was to provide
>>> functionalities to handle both cases.
>>> Regards,
>>> Clement
>>> -----Original Message-----
>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>>> 2008 19:03
>>> To: users@felix.apache.org
>>> Subject: IPojo - universe of components?
>>> Hello,
>>> I was wondering what is iPojo's mission in life: just to make it a
>>> bit easier to code in OSGi or the grand idea to lift the Java
>>> language to a higher abstraction. This philosophical question is
>>> important to me because iPojo like most other DI frameworks seems
>>> highly viral.
>>> For example suppose I start out with a single component class that
>>> creates all it's collaborators with POJN (Plain Old Java New :).
>>> At this point I will have to inject all service dependencies into
>>> this uber-component and have it pass them on to the constructors
>>> of it's collaborators. Soon I get sick of my bad style and decide
>>> to let iPojo manage the collaborators and pass around the
>>> dependencies for me. And as soon as the collaborators are under
>>> iPojo's wing all classes that need them will also have to be iPojo
>>> managed. And so in no time almost all my classes will be
>>> components. All that will be left are light-weight data objects
>>> and static utilities. The former could soon acquire behavior of
>>> their own and will inevitably become components because they will
>>> likely need to collaborate with other components. As for the
>>> static utilities: unless they are bundles of stand-alone purely
>>> functional methods they are a bad style to begin with and should
>>> be re-cast as singleton components. So if I go with the flow I
>>> should have a universe of components.
>>> Is this the way to work with iPojo? Or should restrict iPojo to
>>> only the core graph of long-lived objects that form the basis of
>>> my program and manage the construction, and lifecycle of the more
>>> volatile object generations by hand?
>>> Cheers,
>>> Todor
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Brad Cox <bc...@virtualschool.edu>.
Thanks Kit. My (current) theory is that the osgi standard uses packages
as the unit of reuse. The problem I'm having seems to originate with
that assumption. So its either give up or try something class-based.
The only justification for packages I've seen is that its "more
elegant". Anybody know a more comprehensive reason?
Kit Plummer wrote:
> Brad,
>
> I would warn against the non-standard nature of iPojo. Not to say that
> it is a bad thing, but given the landscape and "components" I think
> you'll struggle with different issues moving in that direction. Sure,
> you may resolve component dependencies - cleaner. But, the risk is that
> your component no longer travels well.
>
> Kit
>
>
> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>
>> I'm totally new to iPOJO but have been pusing components forever. But
>> I'm guessing this fine- vs coarse-grained distinction is precisely the
>> problem I've been struggling with org.jdom, with lots of hand-on help
>> from P. Kriens. So far its defeated both of us.
>>
>> It seems JDOM is what you called a coarse-grained component, developed
>> long before this fine-grained ipojo stuff was around. Deeply entangled
>> with even lower-level dependencies, like Xerces. So I've started
>> looking at iPOJO to see whether that might be a way forward.
>>
>> I'm hoping to find a way to include jdom+dependencies in one of my
>> ipojos so other ipojos can resolve it from there. Seems
>> straightforward on the surface, if I can avoid whatever is breaking
>> bnd now.
>>
>> Clement Escoffier wrote:
>>> Hi,
>>> That’s an interesting question. I would say that it slightly depend
>>> of your use case. However, in one level of abstraction, being
>>> consistent sounds reasonable. To illustrate this, I’m going to
>>> describe two different types of projects choosing the different
>>> strategies: a universe of fine-grain components, and a universe of
>>> coarse-grain components (using regular object collaborators).
>>> In a project aiming to design and implement a residential gateway,
>>> the granularity of components is rather fine-grain. The most part of
>>> the functionalities are implemented inside components and are
>>> available through services, such as devices, technical services, and
>>> internal application services. For this latter case, using iPOJO
>>> composite was crucial to maintain the isolation of internal services
>>> that must not be accessible outside the application (by peer that are
>>> not a part of the application). This granularity was chosen because
>>> of the required flexibility for runtime evolution (application
>>> updates, modifications of the environment…). In this use case,
>>> “everything was dynamic”.
>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>> (Guillaume or/and Francois, correct me if I’m wrong). Each technical
>>> services provided by the JEE server is implemented by iPOJO
>>> components and provided as OSGi services. Two aspects motivated this
>>> choice. First, the Jonas team wanted to reuse the most part of their
>>> code (makes sense right?). Then, the unit of evolution (update) is
>>> the technical service (coarse-grain). So, in conclusion, it’s an open
>>> question ☺. There is no generic answer. iPOJO does not influence one
>>> or another way, because IMHO it depends of the use case. The goal of
>>> iPOJO was to provide functionalities to handle both cases.
>>> Regards,
>>> Clement
>>> -----Original Message-----
>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>>> 2008 19:03
>>> To: users@felix.apache.org
>>> Subject: IPojo - universe of components?
>>> Hello,
>>> I was wondering what is iPojo's mission in life: just to make it a
>>> bit easier to code in OSGi or the grand idea to lift the Java
>>> language to a higher abstraction. This philosophical question is
>>> important to me because iPojo like most other DI frameworks seems
>>> highly viral.
>>> For example suppose I start out with a single component class that
>>> creates all it's collaborators with POJN (Plain Old Java New :). At
>>> this point I will have to inject all service dependencies into this
>>> uber-component and have it pass them on to the constructors of it's
>>> collaborators. Soon I get sick of my bad style and decide to let
>>> iPojo manage the collaborators and pass around the dependencies for
>>> me. And as soon as the collaborators are under iPojo's wing all
>>> classes that need them will also have to be iPojo managed. And so in
>>> no time almost all my classes will be components. All that will be
>>> left are light-weight data objects and static utilities. The former
>>> could soon acquire behavior of their own and will inevitably become
>>> components because they will likely need to collaborate with other
>>> components. As for the static utilities: unless they are bundles of
>>> stand-alone purely functional methods they are a bad style to begin
>>> with and should be re-cast as singleton components. So if I go with
>>> the flow I should have a universe of components.
>>> Is this the way to work with iPojo? Or should restrict iPojo to only
>>> the core graph of long-lived objects that form the basis of my
>>> program and manage the construction, and lifecycle of the more
>>> volatile object generations by hand?
>>> Cheers,
>>> Todor
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
RE: IPojo - universe of components?
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
Just to clarify. iPOJO is not tight to Felix. It also works one other OSGi R4 implementations such as Equinox and KF2. Moreover, iPOJO applications can interact with services implemented with another DI framework. I have iPOJO applications using SCR or Spring-DM services. It also works in the other direction. You can have Spring-DM or SCR components/beans using services developed with iPOJO.
Clement
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: mardi 28 octobre 2008 17:44
To: users@felix.apache.org
Subject: Re: IPojo - universe of components?
Kit,
I would be interested in the issues that concern you. I believe it
should be possible to create components in iPOJO that use basic DoI
techniques that would travel well. Clearly, you can use more advanced
features that won't, but no one forces you to do that.
I am not really sure what "standardness" has to do with the point, since
I am not really aware of a standard in this area, unless you are talking
about DS or the Spring-DM work within the OSGi Alliance. If so, I would
say that there is nothing special about being run through the OSGi
Alliance spec process, other than getting more feedback.
-> richard
Kit Plummer wrote:
> Brad,
>
> I would warn against the non-standard nature of iPojo. Not to say
> that it is a bad thing, but given the landscape and "components" I
> think you'll struggle with different issues moving in that direction.
> Sure, you may resolve component dependencies - cleaner. But, the risk
> is that your component no longer travels well.
>
> Kit
>
>
> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>
>> I'm totally new to iPOJO but have been pusing components forever. But
>> I'm guessing this fine- vs coarse-grained distinction is precisely
>> the problem I've been struggling with org.jdom, with lots of hand-on
>> help from P. Kriens. So far its defeated both of us.
>>
>> It seems JDOM is what you called a coarse-grained component,
>> developed long before this fine-grained ipojo stuff was around.
>> Deeply entangled with even lower-level dependencies, like Xerces. So
>> I've started looking at iPOJO to see whether that might be a way
>> forward.
>>
>> I'm hoping to find a way to include jdom+dependencies in one of my
>> ipojos so other ipojos can resolve it from there. Seems
>> straightforward on the surface, if I can avoid whatever is breaking
>> bnd now.
>>
>> Clement Escoffier wrote:
>>> Hi,
>>> That’s an interesting question. I would say that it slightly depend
>>> of your use case. However, in one level of abstraction, being
>>> consistent sounds reasonable. To illustrate this, I’m going to
>>> describe two different types of projects choosing the different
>>> strategies: a universe of fine-grain components, and a universe of
>>> coarse-grain components (using regular object collaborators).
>>> In a project aiming to design and implement a residential gateway,
>>> the granularity of components is rather fine-grain. The most part of
>>> the functionalities are implemented inside components and are
>>> available through services, such as devices, technical services, and
>>> internal application services. For this latter case, using iPOJO
>>> composite was crucial to maintain the isolation of internal services
>>> that must not be accessible outside the application (by peer that
>>> are not a part of the application). This granularity was chosen
>>> because of the required flexibility for runtime evolution
>>> (application updates, modifications of the environment…). In this
>>> use case, “everything was dynamic”.
>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>>> technical services provided by the JEE server is implemented by
>>> iPOJO components and provided as OSGi services. Two aspects
>>> motivated this choice. First, the Jonas team wanted to reuse the
>>> most part of their code (makes sense right?). Then, the unit of
>>> evolution (update) is the technical service (coarse-grain). So, in
>>> conclusion, it’s an open question ☺. There is no generic answer.
>>> iPOJO does not influence one or another way, because IMHO it depends
>>> of the use case. The goal of iPOJO was to provide functionalities to
>>> handle both cases.
>>> Regards,
>>> Clement
>>> -----Original Message-----
>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>>> 2008 19:03
>>> To: users@felix.apache.org
>>> Subject: IPojo - universe of components?
>>> Hello,
>>> I was wondering what is iPojo's mission in life: just to make it a
>>> bit easier to code in OSGi or the grand idea to lift the Java
>>> language to a higher abstraction. This philosophical question is
>>> important to me because iPojo like most other DI frameworks seems
>>> highly viral.
>>> For example suppose I start out with a single component class that
>>> creates all it's collaborators with POJN (Plain Old Java New :). At
>>> this point I will have to inject all service dependencies into this
>>> uber-component and have it pass them on to the constructors of it's
>>> collaborators. Soon I get sick of my bad style and decide to let
>>> iPojo manage the collaborators and pass around the dependencies for
>>> me. And as soon as the collaborators are under iPojo's wing all
>>> classes that need them will also have to be iPojo managed. And so in
>>> no time almost all my classes will be components. All that will be
>>> left are light-weight data objects and static utilities. The former
>>> could soon acquire behavior of their own and will inevitably become
>>> components because they will likely need to collaborate with other
>>> components. As for the static utilities: unless they are bundles of
>>> stand-alone purely functional methods they are a bad style to begin
>>> with and should be re-cast as singleton components. So if I go with
>>> the flow I should have a universe of components.
>>> Is this the way to work with iPojo? Or should restrict iPojo to only
>>> the core graph of long-lived objects that form the basis of my
>>> program and manage the construction, and lifecycle of the more
>>> volatile object generations by hand?
>>> Cheers,
>>> Todor
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Kit Plummer <ki...@gmail.com>.
Hey Richard.
I can imagine. It was not my intention to present my perspective as
FUD. Sorry 'bout that.
From a consumer of technology point of view our notion of "standard"
is slightly different - especially since Brad and I work in a space
where the use of "standardized" technology is becoming paramount (two
guesses, and the first one doesn't count). In many cases our ability
to utilize any given tech depends on if it is based on an "open"
standard - or not. That said, it is an easier sell to stay close to
the spec.
I completely appreciate segregation of spec and implementation. I
believe you are correct that a spec or standard should and can not
limit the growth of its implementation. And ... not knowing anymore
about iPojo than what has been made available here I'll shut up now,
and go back into my hole. ;)
Kit
On Oct 28, 2008, at 2:32 PM, Richard S. Hall wrote:
> No offense taken, just trying to dispel common misconceptions.
>
> As Clement already stated, iPOJO is in no way tied to Felix. It is
> just a bundle that runs on top of any OSGi framework.
>
> The Felix community takes "pure OSGi" seriously. We would never try
> to tie anyone to Felix for any of our subprojects, unless there was
> no way around it. This should be a FAQ.
>
> Additionally, if we keep letting people think that the only way a
> bundle should be used is if the OSGi Alliance has "blessed" it, we
> will surely stunt the growth of OSGi acceptance.
>
> From the OSGi Alliance's perspective, it might be nice if we were
> the center of the universe, but I believe everyone knows that this
> is not realistic. It is only worthwhile to standardize things when
> multiple implementations are actually possible and/or beneficial.
> Further, it is not good to standardize rapidly changing technology.
> We need experience with it first.
>
> -> richard
>
> Kit Plummer wrote:
>> Hey Richard.
>>
>> Sorry...didn't mean to put anyone on the defensive. My point
>> really was around using core OSGi interfaces versus Felix iPOJO
>> "stuff" - and that notion. I should also apologize because I'm
>> familiar with Brad's work. But, noting specification (OSGi) versus
>> standard probably is worthy too.
>>
>> The real concern is being tied to Felix, rather than just OSGi,
>> nothing more.
>>
>> Kit
>> On Oct 28, 2008, at 9:43 AM, Richard S. Hall wrote:
>>
>>> Kit,
>>>
>>> I would be interested in the issues that concern you. I believe it
>>> should be possible to create components in iPOJO that use basic
>>> DoI techniques that would travel well. Clearly, you can use more
>>> advanced features that won't, but no one forces you to do that.
>>>
>>> I am not really sure what "standardness" has to do with the point,
>>> since I am not really aware of a standard in this area, unless you
>>> are talking about DS or the Spring-DM work within the OSGi
>>> Alliance. If so, I would say that there is nothing special about
>>> being run through the OSGi Alliance spec process, other than
>>> getting more feedback.
>>>
>>> -> richard
>>>
>>> Kit Plummer wrote:
>>>> Brad,
>>>>
>>>> I would warn against the non-standard nature of iPojo. Not to
>>>> say that it is a bad thing, but given the landscape and
>>>> "components" I think you'll struggle with different issues moving
>>>> in that direction. Sure, you may resolve component dependencies
>>>> - cleaner. But, the risk is that your component no longer
>>>> travels well.
>>>>
>>>> Kit
>>>>
>>>>
>>>> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>>>>
>>>>> I'm totally new to iPOJO but have been pusing components
>>>>> forever. But I'm guessing this fine- vs coarse-grained
>>>>> distinction is precisely the problem I've been struggling with
>>>>> org.jdom, with lots of hand-on help from P. Kriens. So far its
>>>>> defeated both of us.
>>>>>
>>>>> It seems JDOM is what you called a coarse-grained component,
>>>>> developed long before this fine-grained ipojo stuff was around.
>>>>> Deeply entangled with even lower-level dependencies, like
>>>>> Xerces. So I've started looking at iPOJO to see whether that
>>>>> might be a way forward.
>>>>>
>>>>> I'm hoping to find a way to include jdom+dependencies in one of
>>>>> my ipojos so other ipojos can resolve it from there. Seems
>>>>> straightforward on the surface, if I can avoid whatever is
>>>>> breaking bnd now.
>>>>>
>>>>> Clement Escoffier wrote:
>>>>>> Hi,
>>>>>> That’s an interesting question. I would say that it slightly
>>>>>> depend of your use case. However, in one level of abstraction,
>>>>>> being consistent sounds reasonable. To illustrate this, I’m
>>>>>> going to describe two different types of projects choosing the
>>>>>> different strategies: a universe of fine-grain components, and
>>>>>> a universe of coarse-grain components (using regular object
>>>>>> collaborators).
>>>>>> In a project aiming to design and implement a residential
>>>>>> gateway, the granularity of components is rather fine-grain.
>>>>>> The most part of the functionalities are implemented inside
>>>>>> components and are available through services, such as devices,
>>>>>> technical services, and internal application services. For this
>>>>>> latter case, using iPOJO composite was crucial to maintain the
>>>>>> isolation of internal services that must not be accessible
>>>>>> outside the application (by peer that are not a part of the
>>>>>> application). This granularity was chosen because of the
>>>>>> required flexibility for runtime evolution (application
>>>>>> updates, modifications of the environment…). In this use
>>>>>> case, “everything was dynamic”.
>>>>>> In the Jonas JEE server, the chosen granularity was coarse-
>>>>>> grain (Guillaume or/and Francois, correct me if I’m wrong).
>>>>>> Each technical services provided by the JEE server is
>>>>>> implemented by iPOJO components and provided as OSGi services.
>>>>>> Two aspects motivated this choice. First, the Jonas team wanted
>>>>>> to reuse the most part of their code (makes sense right?).
>>>>>> Then, the unit of evolution (update) is the technical service
>>>>>> (coarse-grain). So, in conclusion, it’s an open question ☺.
>>>>>> There is no generic answer. iPOJO does not influence one or
>>>>>> another way, because IMHO it depends of the use case. The goal
>>>>>> of iPOJO was to provide functionalities to handle both cases.
>>>>>> Regards,
>>>>>> Clement
>>>>>> -----Original Message-----
>>>>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27
>>>>>> octobre 2008 19:03
>>>>>> To: users@felix.apache.org
>>>>>> Subject: IPojo - universe of components?
>>>>>> Hello,
>>>>>> I was wondering what is iPojo's mission in life: just to make
>>>>>> it a bit easier to code in OSGi or the grand idea to lift the
>>>>>> Java language to a higher abstraction. This philosophical
>>>>>> question is important to me because iPojo like most other DI
>>>>>> frameworks seems highly viral.
>>>>>> For example suppose I start out with a single component class
>>>>>> that creates all it's collaborators with POJN (Plain Old Java
>>>>>> New :). At this point I will have to inject all service
>>>>>> dependencies into this uber-component and have it pass them on
>>>>>> to the constructors of it's collaborators. Soon I get sick of
>>>>>> my bad style and decide to let iPojo manage the collaborators
>>>>>> and pass around the dependencies for me. And as soon as the
>>>>>> collaborators are under iPojo's wing all classes that need them
>>>>>> will also have to be iPojo managed. And so in no time almost
>>>>>> all my classes will be components. All that will be left are
>>>>>> light-weight data objects and static utilities. The former
>>>>>> could soon acquire behavior of their own and will inevitably
>>>>>> become components because they will likely need to collaborate
>>>>>> with other components. As for the static utilities: unless they
>>>>>> are bundles of stand-alone purely functional methods they are a
>>>>>> bad style to begin with and should be re-cast as singleton
>>>>>> components. So if I go with the flow I should have a universe
>>>>>> of components.
>>>>>> Is this the way to work with iPojo? Or should restrict iPojo to
>>>>>> only the core graph of long-lived objects that form the basis
>>>>>> of my program and manage the construction, and lifecycle of the
>>>>>> more volatile object generations by hand?
>>>>>> Cheers,
>>>>>> Todor
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
No offense taken, just trying to dispel common misconceptions.
As Clement already stated, iPOJO is in no way tied to Felix. It is just
a bundle that runs on top of any OSGi framework.
The Felix community takes "pure OSGi" seriously. We would never try to
tie anyone to Felix for any of our subprojects, unless there was no way
around it. This should be a FAQ.
Additionally, if we keep letting people think that the only way a bundle
should be used is if the OSGi Alliance has "blessed" it, we will surely
stunt the growth of OSGi acceptance.
From the OSGi Alliance's perspective, it might be nice if we were the
center of the universe, but I believe everyone knows that this is not
realistic. It is only worthwhile to standardize things when multiple
implementations are actually possible and/or beneficial. Further, it is
not good to standardize rapidly changing technology. We need experience
with it first.
-> richard
Kit Plummer wrote:
> Hey Richard.
>
> Sorry...didn't mean to put anyone on the defensive. My point really
> was around using core OSGi interfaces versus Felix iPOJO "stuff" - and
> that notion. I should also apologize because I'm familiar with Brad's
> work. But, noting specification (OSGi) versus standard probably is
> worthy too.
>
> The real concern is being tied to Felix, rather than just OSGi,
> nothing more.
>
> Kit
> On Oct 28, 2008, at 9:43 AM, Richard S. Hall wrote:
>
>> Kit,
>>
>> I would be interested in the issues that concern you. I believe it
>> should be possible to create components in iPOJO that use basic DoI
>> techniques that would travel well. Clearly, you can use more advanced
>> features that won't, but no one forces you to do that.
>>
>> I am not really sure what "standardness" has to do with the point,
>> since I am not really aware of a standard in this area, unless you
>> are talking about DS or the Spring-DM work within the OSGi Alliance.
>> If so, I would say that there is nothing special about being run
>> through the OSGi Alliance spec process, other than getting more
>> feedback.
>>
>> -> richard
>>
>> Kit Plummer wrote:
>>> Brad,
>>>
>>> I would warn against the non-standard nature of iPojo. Not to say
>>> that it is a bad thing, but given the landscape and "components" I
>>> think you'll struggle with different issues moving in that
>>> direction. Sure, you may resolve component dependencies - cleaner.
>>> But, the risk is that your component no longer travels well.
>>>
>>> Kit
>>>
>>>
>>> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>>>
>>>> I'm totally new to iPOJO but have been pusing components forever.
>>>> But I'm guessing this fine- vs coarse-grained distinction is
>>>> precisely the problem I've been struggling with org.jdom, with lots
>>>> of hand-on help from P. Kriens. So far its defeated both of us.
>>>>
>>>> It seems JDOM is what you called a coarse-grained component,
>>>> developed long before this fine-grained ipojo stuff was around.
>>>> Deeply entangled with even lower-level dependencies, like Xerces.
>>>> So I've started looking at iPOJO to see whether that might be a way
>>>> forward.
>>>>
>>>> I'm hoping to find a way to include jdom+dependencies in one of my
>>>> ipojos so other ipojos can resolve it from there. Seems
>>>> straightforward on the surface, if I can avoid whatever is breaking
>>>> bnd now.
>>>>
>>>> Clement Escoffier wrote:
>>>>> Hi,
>>>>> That’s an interesting question. I would say that it slightly
>>>>> depend of your use case. However, in one level of abstraction,
>>>>> being consistent sounds reasonable. To illustrate this, I’m going
>>>>> to describe two different types of projects choosing the different
>>>>> strategies: a universe of fine-grain components, and a universe of
>>>>> coarse-grain components (using regular object collaborators).
>>>>> In a project aiming to design and implement a residential gateway,
>>>>> the granularity of components is rather fine-grain. The most part
>>>>> of the functionalities are implemented inside components and are
>>>>> available through services, such as devices, technical services,
>>>>> and internal application services. For this latter case, using
>>>>> iPOJO composite was crucial to maintain the isolation of internal
>>>>> services that must not be accessible outside the application (by
>>>>> peer that are not a part of the application). This granularity was
>>>>> chosen because of the required flexibility for runtime evolution
>>>>> (application updates, modifications of the environment…). In this
>>>>> use case, “everything was dynamic”.
>>>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>>>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>>>>> technical services provided by the JEE server is implemented by
>>>>> iPOJO components and provided as OSGi services. Two aspects
>>>>> motivated this choice. First, the Jonas team wanted to reuse the
>>>>> most part of their code (makes sense right?). Then, the unit of
>>>>> evolution (update) is the technical service (coarse-grain). So, in
>>>>> conclusion, it’s an open question ☺. There is no generic answer.
>>>>> iPOJO does not influence one or another way, because IMHO it
>>>>> depends of the use case. The goal of iPOJO was to provide
>>>>> functionalities to handle both cases.
>>>>> Regards,
>>>>> Clement
>>>>> -----Original Message-----
>>>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>>>>> 2008 19:03
>>>>> To: users@felix.apache.org
>>>>> Subject: IPojo - universe of components?
>>>>> Hello,
>>>>> I was wondering what is iPojo's mission in life: just to make it a
>>>>> bit easier to code in OSGi or the grand idea to lift the Java
>>>>> language to a higher abstraction. This philosophical question is
>>>>> important to me because iPojo like most other DI frameworks seems
>>>>> highly viral.
>>>>> For example suppose I start out with a single component class that
>>>>> creates all it's collaborators with POJN (Plain Old Java New :).
>>>>> At this point I will have to inject all service dependencies into
>>>>> this uber-component and have it pass them on to the constructors
>>>>> of it's collaborators. Soon I get sick of my bad style and decide
>>>>> to let iPojo manage the collaborators and pass around the
>>>>> dependencies for me. And as soon as the collaborators are under
>>>>> iPojo's wing all classes that need them will also have to be iPojo
>>>>> managed. And so in no time almost all my classes will be
>>>>> components. All that will be left are light-weight data objects
>>>>> and static utilities. The former could soon acquire behavior of
>>>>> their own and will inevitably become components because they will
>>>>> likely need to collaborate with other components. As for the
>>>>> static utilities: unless they are bundles of stand-alone purely
>>>>> functional methods they are a bad style to begin with and should
>>>>> be re-cast as singleton components. So if I go with the flow I
>>>>> should have a universe of components.
>>>>> Is this the way to work with iPojo? Or should restrict iPojo to
>>>>> only the core graph of long-lived objects that form the basis of
>>>>> my program and manage the construction, and lifecycle of the more
>>>>> volatile object generations by hand?
>>>>> Cheers,
>>>>> Todor
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by Kit Plummer <ki...@gmail.com>.
Hey Richard.
Sorry...didn't mean to put anyone on the defensive. My point really
was around using core OSGi interfaces versus Felix iPOJO "stuff" - and
that notion. I should also apologize because I'm familiar with Brad's
work. But, noting specification (OSGi) versus standard probably is
worthy too.
The real concern is being tied to Felix, rather than just OSGi,
nothing more.
Kit
On Oct 28, 2008, at 9:43 AM, Richard S. Hall wrote:
> Kit,
>
> I would be interested in the issues that concern you. I believe it
> should be possible to create components in iPOJO that use basic DoI
> techniques that would travel well. Clearly, you can use more
> advanced features that won't, but no one forces you to do that.
>
> I am not really sure what "standardness" has to do with the point,
> since I am not really aware of a standard in this area, unless you
> are talking about DS or the Spring-DM work within the OSGi Alliance.
> If so, I would say that there is nothing special about being run
> through the OSGi Alliance spec process, other than getting more
> feedback.
>
> -> richard
>
> Kit Plummer wrote:
>> Brad,
>>
>> I would warn against the non-standard nature of iPojo. Not to say
>> that it is a bad thing, but given the landscape and "components" I
>> think you'll struggle with different issues moving in that
>> direction. Sure, you may resolve component dependencies -
>> cleaner. But, the risk is that your component no longer travels
>> well.
>>
>> Kit
>>
>>
>> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>>
>>> I'm totally new to iPOJO but have been pusing components forever.
>>> But I'm guessing this fine- vs coarse-grained distinction is
>>> precisely the problem I've been struggling with org.jdom, with
>>> lots of hand-on help from P. Kriens. So far its defeated both of us.
>>>
>>> It seems JDOM is what you called a coarse-grained component,
>>> developed long before this fine-grained ipojo stuff was around.
>>> Deeply entangled with even lower-level dependencies, like Xerces.
>>> So I've started looking at iPOJO to see whether that might be a
>>> way forward.
>>>
>>> I'm hoping to find a way to include jdom+dependencies in one of my
>>> ipojos so other ipojos can resolve it from there. Seems
>>> straightforward on the surface, if I can avoid whatever is
>>> breaking bnd now.
>>>
>>> Clement Escoffier wrote:
>>>> Hi,
>>>> That’s an interesting question. I would say that it slightly
>>>> depend of your use case. However, in one level of abstraction,
>>>> being consistent sounds reasonable. To illustrate this, I’m
>>>> going to describe two different types of projects choosing the
>>>> different strategies: a universe of fine-grain components, and a
>>>> universe of coarse-grain components (using regular object
>>>> collaborators).
>>>> In a project aiming to design and implement a residential
>>>> gateway, the granularity of components is rather fine-grain. The
>>>> most part of the functionalities are implemented inside
>>>> components and are available through services, such as devices,
>>>> technical services, and internal application services. For this
>>>> latter case, using iPOJO composite was crucial to maintain the
>>>> isolation of internal services that must not be accessible
>>>> outside the application (by peer that are not a part of the
>>>> application). This granularity was chosen because of the required
>>>> flexibility for runtime evolution (application updates,
>>>> modifications of the environment…). In this use case,
>>>> “everything was dynamic”.
>>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>>>> technical services provided by the JEE server is implemented by
>>>> iPOJO components and provided as OSGi services. Two aspects
>>>> motivated this choice. First, the Jonas team wanted to reuse the
>>>> most part of their code (makes sense right?). Then, the unit of
>>>> evolution (update) is the technical service (coarse-grain). So,
>>>> in conclusion, it’s an open question ☺. There is no generic
>>>> answer. iPOJO does not influence one or another way, because IMHO
>>>> it depends of the use case. The goal of iPOJO was to provide
>>>> functionalities to handle both cases.
>>>> Regards,
>>>> Clement
>>>> -----Original Message-----
>>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27
>>>> octobre 2008 19:03
>>>> To: users@felix.apache.org
>>>> Subject: IPojo - universe of components?
>>>> Hello,
>>>> I was wondering what is iPojo's mission in life: just to make it
>>>> a bit easier to code in OSGi or the grand idea to lift the Java
>>>> language to a higher abstraction. This philosophical question is
>>>> important to me because iPojo like most other DI frameworks seems
>>>> highly viral.
>>>> For example suppose I start out with a single component class
>>>> that creates all it's collaborators with POJN (Plain Old Java
>>>> New :). At this point I will have to inject all service
>>>> dependencies into this uber-component and have it pass them on to
>>>> the constructors of it's collaborators. Soon I get sick of my
>>>> bad style and decide to let iPojo manage the collaborators and
>>>> pass around the dependencies for me. And as soon as the
>>>> collaborators are under iPojo's wing all classes that need them
>>>> will also have to be iPojo managed. And so in no time almost all
>>>> my classes will be components. All that will be left are light-
>>>> weight data objects and static utilities. The former could soon
>>>> acquire behavior of their own and will inevitably become
>>>> components because they will likely need to collaborate with
>>>> other components. As for the static utilities: unless they are
>>>> bundles of stand-alone purely functional methods they are a bad
>>>> style to begin with and should be re-cast as singleton
>>>> components. So if I go with the flow I should have a universe of
>>>> components.
>>>> Is this the way to work with iPojo? Or should restrict iPojo to
>>>> only the core graph of long-lived objects that form the basis of
>>>> my program and manage the construction, and lifecycle of the more
>>>> volatile object generations by hand?
>>>> Cheers,
>>>> Todor
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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: IPojo - universe of components?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Kit,
I would be interested in the issues that concern you. I believe it
should be possible to create components in iPOJO that use basic DoI
techniques that would travel well. Clearly, you can use more advanced
features that won't, but no one forces you to do that.
I am not really sure what "standardness" has to do with the point, since
I am not really aware of a standard in this area, unless you are talking
about DS or the Spring-DM work within the OSGi Alliance. If so, I would
say that there is nothing special about being run through the OSGi
Alliance spec process, other than getting more feedback.
-> richard
Kit Plummer wrote:
> Brad,
>
> I would warn against the non-standard nature of iPojo. Not to say
> that it is a bad thing, but given the landscape and "components" I
> think you'll struggle with different issues moving in that direction.
> Sure, you may resolve component dependencies - cleaner. But, the risk
> is that your component no longer travels well.
>
> Kit
>
>
> On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
>
>> I'm totally new to iPOJO but have been pusing components forever. But
>> I'm guessing this fine- vs coarse-grained distinction is precisely
>> the problem I've been struggling with org.jdom, with lots of hand-on
>> help from P. Kriens. So far its defeated both of us.
>>
>> It seems JDOM is what you called a coarse-grained component,
>> developed long before this fine-grained ipojo stuff was around.
>> Deeply entangled with even lower-level dependencies, like Xerces. So
>> I've started looking at iPOJO to see whether that might be a way
>> forward.
>>
>> I'm hoping to find a way to include jdom+dependencies in one of my
>> ipojos so other ipojos can resolve it from there. Seems
>> straightforward on the surface, if I can avoid whatever is breaking
>> bnd now.
>>
>> Clement Escoffier wrote:
>>> Hi,
>>> That’s an interesting question. I would say that it slightly depend
>>> of your use case. However, in one level of abstraction, being
>>> consistent sounds reasonable. To illustrate this, I’m going to
>>> describe two different types of projects choosing the different
>>> strategies: a universe of fine-grain components, and a universe of
>>> coarse-grain components (using regular object collaborators).
>>> In a project aiming to design and implement a residential gateway,
>>> the granularity of components is rather fine-grain. The most part of
>>> the functionalities are implemented inside components and are
>>> available through services, such as devices, technical services, and
>>> internal application services. For this latter case, using iPOJO
>>> composite was crucial to maintain the isolation of internal services
>>> that must not be accessible outside the application (by peer that
>>> are not a part of the application). This granularity was chosen
>>> because of the required flexibility for runtime evolution
>>> (application updates, modifications of the environment…). In this
>>> use case, “everything was dynamic”.
>>> In the Jonas JEE server, the chosen granularity was coarse-grain
>>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>>> technical services provided by the JEE server is implemented by
>>> iPOJO components and provided as OSGi services. Two aspects
>>> motivated this choice. First, the Jonas team wanted to reuse the
>>> most part of their code (makes sense right?). Then, the unit of
>>> evolution (update) is the technical service (coarse-grain). So, in
>>> conclusion, it’s an open question ☺. There is no generic answer.
>>> iPOJO does not influence one or another way, because IMHO it depends
>>> of the use case. The goal of iPOJO was to provide functionalities to
>>> handle both cases.
>>> Regards,
>>> Clement
>>> -----Original Message-----
>>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>>> 2008 19:03
>>> To: users@felix.apache.org
>>> Subject: IPojo - universe of components?
>>> Hello,
>>> I was wondering what is iPojo's mission in life: just to make it a
>>> bit easier to code in OSGi or the grand idea to lift the Java
>>> language to a higher abstraction. This philosophical question is
>>> important to me because iPojo like most other DI frameworks seems
>>> highly viral.
>>> For example suppose I start out with a single component class that
>>> creates all it's collaborators with POJN (Plain Old Java New :). At
>>> this point I will have to inject all service dependencies into this
>>> uber-component and have it pass them on to the constructors of it's
>>> collaborators. Soon I get sick of my bad style and decide to let
>>> iPojo manage the collaborators and pass around the dependencies for
>>> me. And as soon as the collaborators are under iPojo's wing all
>>> classes that need them will also have to be iPojo managed. And so in
>>> no time almost all my classes will be components. All that will be
>>> left are light-weight data objects and static utilities. The former
>>> could soon acquire behavior of their own and will inevitably become
>>> components because they will likely need to collaborate with other
>>> components. As for the static utilities: unless they are bundles of
>>> stand-alone purely functional methods they are a bad style to begin
>>> with and should be re-cast as singleton components. So if I go with
>>> the flow I should have a universe of components.
>>> Is this the way to work with iPojo? Or should restrict iPojo to only
>>> the core graph of long-lived objects that form the basis of my
>>> program and manage the construction, and lifecycle of the more
>>> volatile object generations by hand?
>>> Cheers,
>>> Todor
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Kit Plummer <ki...@gmail.com>.
Brad,
I would warn against the non-standard nature of iPojo. Not to say
that it is a bad thing, but given the landscape and "components" I
think you'll struggle with different issues moving in that direction.
Sure, you may resolve component dependencies - cleaner. But, the risk
is that your component no longer travels well.
Kit
On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
> I'm totally new to iPOJO but have been pusing components forever.
> But I'm guessing this fine- vs coarse-grained distinction is
> precisely the problem I've been struggling with org.jdom, with lots
> of hand-on help from P. Kriens. So far its defeated both of us.
>
> It seems JDOM is what you called a coarse-grained component,
> developed long before this fine-grained ipojo stuff was around.
> Deeply entangled with even lower-level dependencies, like Xerces. So
> I've started looking at iPOJO to see whether that might be a way
> forward.
>
> I'm hoping to find a way to include jdom+dependencies in one of my
> ipojos so other ipojos can resolve it from there. Seems
> straightforward on the surface, if I can avoid whatever is breaking
> bnd now.
>
> Clement Escoffier wrote:
>> Hi,
>> That’s an interesting question. I would say that it slightly
>> depend of your use case. However, in one level of abstraction,
>> being consistent sounds reasonable. To illustrate this, I’m going
>> to describe two different types of projects choosing the different
>> strategies: a universe of fine-grain components, and a universe of
>> coarse-grain components (using regular object collaborators).
>> In a project aiming to design and implement a residential gateway,
>> the granularity of components is rather fine-grain. The most part
>> of the functionalities are implemented inside components and are
>> available through services, such as devices, technical services,
>> and internal application services. For this latter case, using
>> iPOJO composite was crucial to maintain the isolation of internal
>> services that must not be accessible outside the application (by
>> peer that are not a part of the application). This granularity was
>> chosen because of the required flexibility for runtime evolution
>> (application updates, modifications of the environment…). In this
>> use case, “everything was dynamic”.
>> In the Jonas JEE server, the chosen granularity was coarse-grain
>> (Guillaume or/and Francois, correct me if I’m wrong). Each
>> technical services provided by the JEE server is implemented by
>> iPOJO components and provided as OSGi services. Two aspects
>> motivated this choice. First, the Jonas team wanted to reuse the
>> most part of their code (makes sense right?). Then, the unit of
>> evolution (update) is the technical service (coarse-grain). So, in
>> conclusion, it’s an open question ☺. There is no generic answer.
>> iPOJO does not influence one or another way, because IMHO it
>> depends of the use case. The goal of iPOJO was to provide
>> functionalities to handle both cases.
>> Regards,
>> Clement
>> -----Original Message-----
>> From: Todor Boev [mailto:t.boev@prosyst.bg] Sent: lundi 27 octobre
>> 2008 19:03
>> To: users@felix.apache.org
>> Subject: IPojo - universe of components?
>> Hello,
>> I was wondering what is iPojo's mission in life: just to make it a
>> bit easier to code in OSGi or the grand idea to lift the Java
>> language to a higher abstraction. This philosophical question is
>> important to me because iPojo like most other DI frameworks seems
>> highly viral.
>> For example suppose I start out with a single component class that
>> creates all it's collaborators with POJN (Plain Old Java New :). At
>> this point I will have to inject all service dependencies into this
>> uber-component and have it pass them on to the constructors of it's
>> collaborators. Soon I get sick of my bad style and decide to let
>> iPojo manage the collaborators and pass around the dependencies for
>> me. And as soon as the collaborators are under iPojo's wing all
>> classes that need them will also have to be iPojo managed. And so
>> in no time almost all my classes will be components. All that will
>> be left are light-weight data objects and static utilities. The
>> former could soon acquire behavior of their own and will inevitably
>> become components because they will likely need to collaborate with
>> other components. As for the static utilities: unless they are
>> bundles of stand-alone purely functional methods they are a bad
>> style to begin with and should be re-cast as singleton components.
>> So if I go with the flow I should have a universe of components.
>> Is this the way to work with iPojo? Or should restrict iPojo to
>> only the core graph of long-lived objects that form the basis of my
>> program and manage the construction, and lifecycle of the more
>> volatile object generations by hand?
>> Cheers,
>> Todor
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: IPojo - universe of components?
Posted by Brad Cox <bc...@virtualschool.edu>.
I'm totally new to iPOJO but have been pusing components forever. But
I'm guessing this fine- vs coarse-grained distinction is precisely the
problem I've been struggling with org.jdom, with lots of hand-on help
from P. Kriens. So far its defeated both of us.
It seems JDOM is what you called a coarse-grained component, developed
long before this fine-grained ipojo stuff was around. Deeply entangled
with even lower-level dependencies, like Xerces. So I've started looking
at iPOJO to see whether that might be a way forward.
I'm hoping to find a way to include jdom+dependencies in one of my
ipojos so other ipojos can resolve it from there. Seems straightforward
on the surface, if I can avoid whatever is breaking bnd now.
Clement Escoffier wrote:
> Hi,
>
> That’s an interesting question. I would say that it slightly depend of your use case. However, in one level of abstraction, being consistent sounds reasonable.
>
> To illustrate this, I’m going to describe two different types of projects choosing the different strategies: a universe of fine-grain components, and a universe of coarse-grain components (using regular object collaborators).
>
> In a project aiming to design and implement a residential gateway, the granularity of components is rather fine-grain. The most part of the functionalities are implemented inside components and are available through services, such as devices, technical services, and internal application services. For this latter case, using iPOJO composite was crucial to maintain the isolation of internal services that must not be accessible outside the application (by peer that are not a part of the application). This granularity was chosen because of the required flexibility for runtime evolution (application updates, modifications of the environment…). In this use case, “everything was dynamic”.
>
> In the Jonas JEE server, the chosen granularity was coarse-grain (Guillaume or/and Francois, correct me if I’m wrong). Each technical services provided by the JEE server is implemented by iPOJO components and provided as OSGi services. Two aspects motivated this choice. First, the Jonas team wanted to reuse the most part of their code (makes sense right?). Then, the unit of evolution (update) is the technical service (coarse-grain).
>
> So, in conclusion, it’s an open question ☺. There is no generic answer. iPOJO does not influence one or another way, because IMHO it depends of the use case. The goal of iPOJO was to provide functionalities to handle both cases.
>
> Regards,
>
> Clement
>
> -----Original Message-----
> From: Todor Boev [mailto:t.boev@prosyst.bg]
> Sent: lundi 27 octobre 2008 19:03
> To: users@felix.apache.org
> Subject: IPojo - universe of components?
>
> Hello,
> I was wondering what is iPojo's mission in life: just to make it a bit
> easier to code in OSGi or the grand idea to lift the Java language to a
> higher abstraction. This philosophical question is important to me
> because iPojo like most other DI frameworks seems highly viral.
>
> For example suppose I start out with a single component class that
> creates all it's collaborators with POJN (Plain Old Java New :). At this
> point I will have to inject all service dependencies into this
> uber-component and have it pass them on to the constructors of it's
> collaborators. Soon I get sick of my bad style and decide to let iPojo
> manage the collaborators and pass around the dependencies for me. And as
> soon as the collaborators are under iPojo's wing all classes that need
> them will also have to be iPojo managed. And so in no time almost all my
> classes will be components. All that will be left are light-weight data
> objects and static utilities. The former could soon acquire behavior of
> their own and will inevitably become components because they will likely
> need to collaborate with other components. As for the static utilities:
> unless they are bundles of stand-alone purely functional methods they
> are a bad style to begin with and should be re-cast as singleton
> components. So if I go with the flow I should have a universe of components.
>
> Is this the way to work with iPojo? Or should restrict iPojo to only the
> core graph of long-lived objects that form the basis of my program and
> manage the construction, and lifecycle of the more volatile object
> generations by hand?
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Clement,
The feature we were discussing about instance "lifetime" is also
relevant to this discussion.
-> richard
Clement Escoffier wrote:
> Hi,
>
> That’s an interesting question. I would say that it slightly depend of your use case. However, in one level of abstraction, being consistent sounds reasonable.
>
> To illustrate this, I’m going to describe two different types of projects choosing the different strategies: a universe of fine-grain components, and a universe of coarse-grain components (using regular object collaborators).
>
> In a project aiming to design and implement a residential gateway, the granularity of components is rather fine-grain. The most part of the functionalities are implemented inside components and are available through services, such as devices, technical services, and internal application services. For this latter case, using iPOJO composite was crucial to maintain the isolation of internal services that must not be accessible outside the application (by peer that are not a part of the application). This granularity was chosen because of the required flexibility for runtime evolution (application updates, modifications of the environment…). In this use case, “everything was dynamic”.
>
> In the Jonas JEE server, the chosen granularity was coarse-grain (Guillaume or/and Francois, correct me if I’m wrong). Each technical services provided by the JEE server is implemented by iPOJO components and provided as OSGi services. Two aspects motivated this choice. First, the Jonas team wanted to reuse the most part of their code (makes sense right?). Then, the unit of evolution (update) is the technical service (coarse-grain).
>
> So, in conclusion, it’s an open question ☺. There is no generic answer. iPOJO does not influence one or another way, because IMHO it depends of the use case. The goal of iPOJO was to provide functionalities to handle both cases.
>
> Regards,
>
> Clement
>
> -----Original Message-----
> From: Todor Boev [mailto:t.boev@prosyst.bg]
> Sent: lundi 27 octobre 2008 19:03
> To: users@felix.apache.org
> Subject: IPojo - universe of components?
>
> Hello,
> I was wondering what is iPojo's mission in life: just to make it a bit
> easier to code in OSGi or the grand idea to lift the Java language to a
> higher abstraction. This philosophical question is important to me
> because iPojo like most other DI frameworks seems highly viral.
>
> For example suppose I start out with a single component class that
> creates all it's collaborators with POJN (Plain Old Java New :). At this
> point I will have to inject all service dependencies into this
> uber-component and have it pass them on to the constructors of it's
> collaborators. Soon I get sick of my bad style and decide to let iPojo
> manage the collaborators and pass around the dependencies for me. And as
> soon as the collaborators are under iPojo's wing all classes that need
> them will also have to be iPojo managed. And so in no time almost all my
> classes will be components. All that will be left are light-weight data
> objects and static utilities. The former could soon acquire behavior of
> their own and will inevitably become components because they will likely
> need to collaborate with other components. As for the static utilities:
> unless they are bundles of stand-alone purely functional methods they
> are a bad style to begin with and should be re-cast as singleton
> components. So if I go with the flow I should have a universe of components.
>
> Is this the way to work with iPojo? Or should restrict iPojo to only the
> core graph of long-lived objects that form the basis of my program and
> manage the construction, and lifecycle of the more volatile object
> generations by hand?
>
> Cheers,
> Todor
>
> ---------------------------------------------------------------------
> 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: IPojo - universe of components?
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
That’s an interesting question. I would say that it slightly depend of your use case. However, in one level of abstraction, being consistent sounds reasonable.
To illustrate this, I’m going to describe two different types of projects choosing the different strategies: a universe of fine-grain components, and a universe of coarse-grain components (using regular object collaborators).
In a project aiming to design and implement a residential gateway, the granularity of components is rather fine-grain. The most part of the functionalities are implemented inside components and are available through services, such as devices, technical services, and internal application services. For this latter case, using iPOJO composite was crucial to maintain the isolation of internal services that must not be accessible outside the application (by peer that are not a part of the application). This granularity was chosen because of the required flexibility for runtime evolution (application updates, modifications of the environment…). In this use case, “everything was dynamic”.
In the Jonas JEE server, the chosen granularity was coarse-grain (Guillaume or/and Francois, correct me if I’m wrong). Each technical services provided by the JEE server is implemented by iPOJO components and provided as OSGi services. Two aspects motivated this choice. First, the Jonas team wanted to reuse the most part of their code (makes sense right?). Then, the unit of evolution (update) is the technical service (coarse-grain).
So, in conclusion, it’s an open question ☺. There is no generic answer. iPOJO does not influence one or another way, because IMHO it depends of the use case. The goal of iPOJO was to provide functionalities to handle both cases.
Regards,
Clement
-----Original Message-----
From: Todor Boev [mailto:t.boev@prosyst.bg]
Sent: lundi 27 octobre 2008 19:03
To: users@felix.apache.org
Subject: IPojo - universe of components?
Hello,
I was wondering what is iPojo's mission in life: just to make it a bit
easier to code in OSGi or the grand idea to lift the Java language to a
higher abstraction. This philosophical question is important to me
because iPojo like most other DI frameworks seems highly viral.
For example suppose I start out with a single component class that
creates all it's collaborators with POJN (Plain Old Java New :). At this
point I will have to inject all service dependencies into this
uber-component and have it pass them on to the constructors of it's
collaborators. Soon I get sick of my bad style and decide to let iPojo
manage the collaborators and pass around the dependencies for me. And as
soon as the collaborators are under iPojo's wing all classes that need
them will also have to be iPojo managed. And so in no time almost all my
classes will be components. All that will be left are light-weight data
objects and static utilities. The former could soon acquire behavior of
their own and will inevitably become components because they will likely
need to collaborate with other components. As for the static utilities:
unless they are bundles of stand-alone purely functional methods they
are a bad style to begin with and should be re-cast as singleton
components. So if I go with the flow I should have a universe of components.
Is this the way to work with iPojo? Or should restrict iPojo to only the
core graph of long-lived objects that form the basis of my program and
manage the construction, and lifecycle of the more volatile object
generations by hand?
Cheers,
Todor
---------------------------------------------------------------------
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